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1.0  INTRODUCTION 


This  report  documents  the  work  accomplished  in  the  Diagnostic  System 
Architecture  Study  (Task  Order  4.0  of  the  Development  of  Life  Prediction  Capabilities  for 
Liquid  Propellant  Rocket  Engines  program,  Contract  NAS 3-25883). 

The  objectives  of  this  task  were  (1)  analyze  the  current  process  used  to  make  an 
assessment  of  engine  and  component  health  after  each  test  or  flight  firing  of  an  SSME,  (2) 
develop  an  approach  and  a  specific  set  of  objectives  and  requirements  for  computer 
automated  diagnostic  processing  during  the  post  fire  health  assessment,  and  (3)  list  and 
provide  high  level  descriptions  of  the  software  applications  which  need  to  be  developed. 

The  first  two  of  these  objectives  were  addressed  in  Task  1  of  this  study.  Section  3 
of  this  report  discusses  the  current  system  of  diagnostics,  specific  user  requirements  and 
the  overall  approach  recommended  to  automate  these  user  needs. 

The  final  objective  of  the  study  was  to  describe  the  software  required  to  develop 
this  overall  approach.  This  was  accomplished  in  Task  2  and  the  results  are  discussed  in 
Section  4  of  this  report. 

Finally,  a  brief  outline  for  the  development  and  implementation  of  this  system  was 
prepared.  Section  5  of  this  report  describes  a  recommendation  for  the  phased  development, 
testing,  and  implementation  of  the  system. 


This  page  left  intentionally  blank. 
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2.0  SUMMARY 


The  diagnostic  system  architecture  study  was  a  four  month  effort  which 
accomplished  three  major  objectives.  The  three  objectives  were  to  (1)  analyze  the  current 
process  used  in  making  an  assessment  of  engine  and  component  health  after  each  test  or 
flight  firing  of  an  SSME,  (2)  identify  specific  system  objectives  and  an  approach  to  the 
development  of  automated  diagnostic  processing  during  post  fire  health  assessment,  and 
(3)  list  and  provide  high  level  descriptions  of  software  applications  needed  to  implement  the 
approach. 

The  first  objective  was  met  through  interviews  with  people  who  were  or  are 
currently  involved  in  post-fire  health  assessment  of  the  SSME.  Analysis  of  the  current 
procedures  used  to  make  health  assessments  and  specific  system  requirements  were 
formulated.  The  source  and  attributes  of  the  data  used  to  make  health  assessments  were 
traced  and  the  procedures,  (both  manual  and  computerized)  which  are  used  to  generate  and 
present  the  diagnostic  evaluations  of  engine  and  component  health  were  observed  and 
documented.  Figure  2-1  describes  the  current  overall  process  of  post  test  health 
assessment  of  the  SSME.  Figure  2-2  shows  the  current  computing  environment  used  for 
post  test  diagnostics. 

The  second  objective  was  the  development  of  an  approach  to  enhance  the  diagnostic 
nrocess  by  applying  automated  diagnostic  tools.  Figure  2-3  summarizes  the  distributed 
architecture  of  the  recommended  system.  This  architecture  was  designed  to  solve  problems 
observed  in  the  current  diagnostic  procedures  and  to  address  specific  user  requirements  and 
desired  functionality.  The  distributed  architecture  of  the  system  allows  the  utilization  of 
both  the  existing  computer  systems  and  the  hardware  upgrades  (i.e.,  the  Sun  workstations 
and  VAX  6320)  planned  under  the  Life  Prediction  contract  and  at  MSFC. 

The  third  objective  of  this  study  was  the  identification,  organization  and  description 
of  the  software  required  to  implement  this  approach.  Figure  2-4  summarizes  the  software 
modules  and  applications  required  for  implementation  of  the  system.  The  complete 
diagnostic  system  is  organized  into  five  major  modules  which  provide  management  and 
integration  of  the  various  data  sources,  statistical  analysis  and  graphical  presentation  of  the 
hot  fire  data  data,  automated  data  evaluation,  expen-system  based  health  assessments,  and 
utilities  for  system  administration  and  maintenance. 

Finally,  a  brief  outline  for  the  development  and  implementation  of  this  system  was 
prepared.  Figure  2-5  shows  a  scheme  for  the  phased  implementation  of  these  capabilities. 
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FIGURE  2-1  The  Overall  Process  of  Post  Test  Diagnostic  Assessment 
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FIGURE  2-2  Current  Computing  Environment  for  Post  Test  Diagnostics 


ssc 

CADS/FR 

■  - 1 

38-40 


_  ^ 

FLIGHT 

OPTICAL 

3GB  On  Line 
-60  Tests 


FILE  SERVER  -  VAX 


Extracted 

Data 


Extraction 

Requests 


Hi-Capacity 

Channel 

—  t 


2a 


f— n 

ANOMALIES 


SSME 

DATA 


CANOGA  PARK 


TRACER 


f — ^  f~— n 

INSPECTION  CONFIGURATION 
REPORTS 


COMMON  SOFTWARE 
ENVIRONMENT 


•  COMPUTER  AIDED  ENGINEERING  (CAE) 

-  STATISTICS/ANALYSIS 

-  CALCULATIONS 

-  PLOTTING  (2D/3D) 

-  WINDOWS 

•  SPECIAL  APPLICATIONS 

-  START 

-  MAIN  STAGE 

-  SHUTDOWN 

-  2a  EXCEPTIONS 

-  FEATURE  EXTRACTION 

-  MODEL  ISP,  C2,  KF 

-  SENSOR  ANALYTIC  REDUNDANCY 

■  EXPERT  AIDED  DIAGNOSTICS 

-  FEATURE  RECALL 

-  ANOMALY  ASSOCIATIONS 

-  USER  GENERATED  PROCESSES 

-  DIAGNOSIS  CREATION 


,  Integrated 
Database 


Color  Graphics 
-  Hi  Res 
■  12-20  MIPS 
8-12  MByte  RAM 
•  Mouse  Driven 


NON-PROGRAMMING 

ENVIRONMENT 


FIGURE  2-3  The  Proposed  Diagnostic  System  Will  Be  Built  On  Planned  MSFC 
Computer  Upgrades 


6 


Anomalies 

Plotting 

Sensor  Validation 

Feature  Identification 

Security 

2-Sigma  Data 

Statistical  Analysis 

Startup  Analysis 

Features_to_Anomalies 

Install 

Configurations 

Inspections 

Test  Data 

Specifications 

Report  Generation 

Signal  Processing 

Main  Stage  Analysis 

Shutdown  Analysis 

2  Sigma  Exceptions 

Green  Run  Analysis 

Power  Balance  Model 

Transient  Analysis 

Expert-Aided  Diagnostics 

Advanced  Diagnostics 

Document 

FIGURE  2-4  Overall  Organization  of  Diagnostic  System 


7 


8 


FIGURE  2-5  Health  Assessment  Workstation  Implementation  Plan 


3.0  TASK  1  -  SELECT  APPROACH 


3.1  INTRODUCTION 

This  section  of  the  report  presents  an  analysis  of  the  current  approach  to  post  fire 
diagnostics  and  health  assessment.  Specific  areas  of  the  current  system  which  may  be 
improved  through  the  application  of  intelligent  automated  tools  are  identified  and  discussed. 
Finally,  a  conceptual  design  for  an  automated  system  to  aid  the  diagnostic  process  is 
presented  and  specific  uses  and  benefits  of  the  system  are  detailed. 

A  detailed  understanding  of  the  current  diagnostic  procedures  and  data  flow  came 
through  discussion  with  people  involved  in  post  fire  diagnostics  of  the  SSME.  This  list  of 
expens  included  personnel  from  NASA-MSFC,  NASA-LeRC  and  NASA  contractors  from 
Martin  Marietta,  Aerojet,  Boeing  Computer  Services,  and  Rocketdyne.  Many  of  these 
people  were  interviewed  in  person  during  a  trip  to  NASA-MSFC,  which  provided  an 
opportunity  to  observe  first  hand  the  diagnostic  process  and  current  data  handling 
procedures. 

From  these  interviews,  specific  user  requirements  emerged.  Each  person 
interviewed  was  given  the  opportunity  to  describe  computer-based  tools  which  they  would 
find  useful  during  post  fire  data  evaluation.  More  often  than  not,  they  had  some  very  firm 
ideas  of  what  they  wanted  and  needed. 

A  conceptual  approach  was  developed  integrating  these  new  capabilities  with 
enhancements  to  the  current  system.  This  contrasts  with  providing  a  totally  independent 
and  isolated  diagnostic  system.  The  approach  utilizes  NASA's  current  and  to-be-delivered 
computer  hardware  and  software.  While  at  NASA-MSFC  the  conceptual  design  of  the 
system  was  discussed  with  potential  users  and  administrators  of  the  system.  In  these 
meetings,  the  approach  was  well  received  and  users  confirmed  that  the  approach  was 
responsive  to  their  objectives  and  requirements. 


3.2  CURRENT  DIAGNOSTIC  PROCEDURES 

During  our  analysis  of  the  current  approach  to  post  fire  diagnostics,  emphasis  was 
placed  on  the  evaluation  of  test  (as  opposed  to  flight)  data  because  evaluation  of  test  data  is 
the  larger  job  with  more  potential  operations  cost  benefit.  There  are  two  reasons  for  this. 
First,  more  data  is  evaluated  from  the  test  stand  than  from  the  flight  engines  because  there 
are  many  more  engine  tests  than  orbiter  flights.  Second,  the  instrumentation  set  is  larger  on 
the  test  stand  than  on  the  flight  engines.  This  enables  diagnostic  evaluations  and  special 
studies  based  on  test  stand  data  which  are  not  otherwise  available  from  flight  data.  Still, 
there  are  many  similarities  in  the  procedures  and  techniques  used  to  evaluate  flight  data,  and 
it  is  safe  to  say  that  a  diagnostic  system  which  can  effectively  aid  the  evaluation  of  test 
stand  data  can  also  be  applied  to  the  analys  s  of  flight  engine  data. 

The  procedures  used  during  post  fire  diagnostics  have  evolved  with  the  SSME  and 
have  become  efficient  through  repetition,  discipline,  and  the  dedication  and  enthusiasm  of 
the  individuals  involved.  During  this  evolution,  a  number  of  guidelines  have  remained 
constant  which  must  be  recognized  in  any  attempts  to  improve  the  system.  One  of  these 
guidelines  is  that  no  tests  are  conducted  until  the  data  from  previous  firings  has  been 
thoroughly  reviewed  and  evaluated.  This  imparts  a  severe  time  constraint  on  the 
evaluators.  Post  test  diagnostics  and  health  assessments  are  often  started  and  completed 
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within  24  hours  of  a  rest  firing.  Frequently,  all  instrumentation  traces  are  reviewed  and 
diagnostic  conclusions  formally  presented  within  the  same  workday. 

A  second  guideline  used  is  that  independent,  corroborative  assessment  of  the  data 
be  performed.  This  extends  throughout  the  organizations  which  evaluate  the  data.  At  the 
highest  level,  teams  from  Rocketdyne  and  MSFC  make  independent  evaluations  of  the  test 
data.  Within  each  diagnostic  team,  independent  analysis  and  evidence  is  presented  by  the 
test  engineers  on  turbomachinery,  dynamics,  combustion  devices,  and  systems  groups. 
The  principle  of  independent  corroboration  of  the  diagnostic  conclusions  is  maintained  in 
all  cases.  Figure  3-1  presents  the  structure  of  the  organizations  which  support  the  post  fire 
data  evaluations. 

Figure  3-2  shows  the  overall  post  test  diagnostic  cycle  for  the  SSME.  Each  circle  is 
numbered  indexing  it  to  more  detailed  diagrams  shown  in  subsequent  figures.  The  focus 
of  this  program  will  be  in  defining  and  improving  process  3.0  which  is  titled  "Perform 
Diagnostic  Assessment."  This  is  the  process  where  four  major  groups  analyze  the  data 
determining  if  the  test  objectives  were  met  and  if  there  were  any  observations,  anomalies, 
or  failures  which  may  impact  the  readiness  of  the  engine  for  subsequent  tests.  However,  to 
fully  analyze  the  diagnostic  process,  and  to  enable  improvements  in  the  system,  the  other 
processes,  particularly  numbers  1.0  and  2.0  of  Figure  3-2,  were  also  examined  in  detail. 
In  these  processes,  data  is  transferred  from  the  test  stand  and  compiled  into  the  test  data 
books. 


Figure  3-3  shows  some  details  of  the  process  used  to  transfer  data  from  the  test 
stand  to  the  data  processing  center  at  Marshall  Space  Flight  Center.  Separate  recording 
systems  are  used  to  capture  the  CADS,  Facility,  and  Analog  data.  After  the  digital  sets 
(CADS  and  Facility)  are  converted  to  engineering  units,  they  are  transferred  via  telemetry  to 
a  Perkin  Elmer  computer  (PE4)  at  MSFC.  In  parallel,  the  analog  data  is  digitized  and 
telemetered  to  the  same  PE4  system  at  MSFC.  Analog  tapes  are  also  available  for 
processing  on  one  of  two  Masscomp  computer  systems  separately  administered  and 
maintained  by  the  Dynamics  group. 

The  PE4  system  is  capable  of  storing  up  to  38-40  tests  of  CADS  and  Facility  data 
and  one  (1)  test  of  transformed  analog  data  on  line.  Tape  backups  are  archived  for  each  set 
of  test  data.  Administration  and  maintenance  of  the  PE4  system  is  performed  by 
contractors  from  NTI. 

Once  the  data  has  been  received  and  backed  up  at  MSFC,  contractors  from  Boeing 
Computer  Services  make  the  test  data  books  (process  2.0  of  Figure  3-2).  At  the  heart  of 
this  process  is  a  FORTRAN  program  on  the  PE4  called  Plot.  This  program  is  used  to 
construct  a  standard  set  of  graphs  showing  a  sensor  value  versus  time.  The  test  data  books 
are  complete  by  the  beginning  of  the  day  after  a  test.  Special  plots,  such  as  expanded 
scales  on  one  or  more  axes,  or  plots  of  one  sensor  against  another  are  constructed  upon 
special  request  to  the  Boeing  support  personnel,  or  by  an  interactive  session  with  the  Plot 
program.  Presentation  quality  charts  with  annotation  or  regression  fits  of  the  data  are 
constructed  by  downloading  selected  data  via  modem  from  the  PE4  to  a  PC  or  Macintosh. 
DeltaGraph,  a  Macintosh  statistics/graphics  package,  is  used  to  construct  these  presentation 
quality  charts. 
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FIGURE  3-1  Organization  of  Post  Test  Diagnostic  Teams 


FIGURE  3-2  The  Overall  Process  of  Post  Test  Diagnostic  Assessment 


FIGURE  3-3  Transfer  of  Data  from  Test  Stand  to  MSFC 


Experts  from  each  of  the  four  major  disciplines  shown  in  Figure  3-1  evaluate  the 
data  contained  in  the  test  data  book  (process  3.0  of  Figure  3-2).  Possible  sensor  failures 
are  identified  by  visual  examination  of  the  temporal  plots  and  are  then  discussed  and 
resolved  with  instrumentation  specialists.  Unexpected  observations  or  anomalous  engine 
behaviors  are  also  identified  through  visual  inspection  of  the  temporal  plots.  Experts  from 
each  discipline  consult  with  one  another,  or  with  test  engineers  at  Stennis  Space  Center 
when  an  unusual  data  trace  is  observed.  Results  from  manual  post  test  inspection  of  the 
hardware  are  available,  but  not  normally  consulted  unless  an  observation  is  made  from  the 
data  traces  or  an  unsatisfactory  condition  is  observed  during  the  inspection.  Access  to 
historical  sensor  data  is  generally  limited  to  two  previous  cases  which  are  presented  with 
the  standard  data  plots.  Previously  observed  failure  signatures  are  not  generally  available 
and  are  recognized  only  through  the  experience  and  expertise  of  the  individual  evaluators. 

Unusual  occurrences  or  performance  outside  the  relevant  specifications  are  recorded 
via  the  UCR  or  RID  systems.  These  test  events  are  formally  discussed  internally  at  the 
post  test  data  review  and  externally  with  Rocketdyne  at  the  Pre-Test  Readiness  Review. 
Conclusions  from  evaluating  of  the  test  data  are  recorded  in  a  test  summary  prepared  by  the 
Systems  Group. 

The  Systems  Group  at  MSFC  has  taken  responsibility  for  maintaining  historical  test 
records.  They  prepare  the  test  summary  for  each  hot  fire  test  which  is  a  compilation  of 
selected  plots  from  the  test  data  book.  In  addition,  they  maintain  databases  on  an  IBM-PC 
which  records  hot-fire  test  descriptions,  engine  hardware  configurations,  test  anomalies, 
descriptions  indications,  resolutions  and  results  of  inspection  reports,  and  statistical  2- 
sigma  bands  around  sensor  values  recorded  at  various  steady  state  operating  points.  These 
applications  are  all  independent  of  one  another  and  the  data  is  entered  and  updated 
manually. 

Figure  3-4  shows  a  schematic  of  the  overall  computing  environment  used  for  post 
test  diagnostics  by  the  engine  Systems,  Combustion  Devices,  and  Turbomachinery  groups 
at  MSFC.  Shown  on  this  figure  is  the  Perkin  Elmer  4  system  which  is  used  to  receive, 
store  and  archive  the  test  data,  the  Tektronics  terminals  which  supports  past  test  analysis 
and  the  modem  links  to  IBM-PC  and/or  Macintosh  computers. 


3.3  USER  OBJECTIVES  AND  REQUIREMENTS 

This  section  describes  potential  improvements  to  the  current  diagnostic  process 
through  the  use  of  automated  tools.  It  is  not  intended  to  criticize  the  diagnostic  teams  or 
process  at  MSFC.  Indeed,  the  greatest  asset  of  the  current  diagnostic  system  is  the  quality 
and  dedication  of  the  people  who  process  and  evaluate  the  test  data.  Rather,  this  section  of 
the  report  will  focus  on  areas  of  the  diagnostic  process  for  which  significant  benefit  can  be 
realized  through  automation. 

As  discussed  in  the  previous  section,  the  current  diagnostic  process  consists  of  five 
distinct  steps.  These  steps  are  1)  Transfer  Data,  2)  Preparation  of  Data  Books,  3)  Conduct 
Diagnostic  Evaluations,  4)  Post  Test  Data  Review,  and  5)  Test  Readiness  Review. 
Difficulties  associated  with  each  of  these  steps  will  be  discussed. 
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FIGURE  3-4  Current  Computing  Environment  for  Post  Test  Diagnostics 


3.3.1  Transfer  of  Data 


The  recording  and  communications  systems  which  captures  and  transmits  the  test 
data  appear  to  be  effective  and  reliable.  The  PE4  system  and  support  staff  are  well 
established  and  adequately  handle  data  receipt,  on  line  storage  and  data  archival. 
Particularly  important  is  the  PE4's  ability  to  receive  and  record  real  time  VDT  transmissions 
from  flight  missions  of  the  Shuttle. 

The  most  significant  limitation  of  the  PE4  system  is  the  limited  storage  of  only  a 
relatively  small  number  of  test  cases.  Only  one  (1)  set  of  dynamics  data  are  available  on 
line.  Additionally,  up  to  40  CADS  and  Facility  sets  (approximately  3  months  worth  of 
tests)  are  available  at  any  given  time.  This  storage  issue  is  being  addressed  through  the 
addition  of  optical  disk  drives.  Although  these  drives  are  slow,  they  are  capable  of  holding 
up  to  60  additional  tests  of  CADS  and  Facility  data.  Tne  Dynamics  data  will  soon  be  stored 
on  two  new  Masscomp  systems  which  will  be  supported  by  the  Dynamics  group. 

This  study  does  not  recommend  any  significant  changes  to  the  current  system  of 
data  transmission,  storage,  and  archival.  The  current  procedures  should  be  used  by  the 
new  Diagnostic  System. 

3.3.2  Preparation  of  Test  Data  Books 

Production  of  the  test  data  books  is  one  of  the  major  deficiencies  which  can  be 
addressed  through  the  use  of  improved  automation  tools.  A  number  of  specific  problems 
in  the  current  process  are  discussed  below. 

First,  production  of  a  test  data  book  requires  at  least  4  to  5  hours.  This  is  a  major 
bottleneck  in  the  diagnostic  process  which  is  currently  addressed  by  assigning  production 
personnel  on  off  shifts  to  producing  the  book.  One  reason  the  production  requires  so  much 
time  is  that  each  data  book  contains  approximately  300  separate  plots  of  sensor  values 
versus  time.  We  have  not  explicitly  identified  the  need  for  each  of  these  plots;  however, 
we  sense  from  our  interviews  that  a  more  refined  construct  of  the  data  presented  may 
reduce  the  number  of  individual  plots  required. 

Second,  the  data  books  contain  a  very  limited  set  of  automated  evaluations.  No 
comparisons  to  standard  acceptance  specifications  or  even  simple  2  sigma  envelopes  are 
presented.  The  individual  evaluator  is  responsible  for  providing  the  other  data  necessary  to 
identify  relevant  test  events  or  anomalies. 

Third,  the  program  which  generates  the  test  data  books  (the  Plot  program)  is  not 
very  powerful  or  flexible.  The  Plot  program  produces  the  data  books  by  executing  a 
runstream  file  (a  macro-like  file  of  keystrokes)  which  generates  the  standard  plots.  Only  a 
limited  number  of  standard  plot  formats  are  available  and  construction  of  new  formats  or 
data  manipulations  requires  modification  of  the  Plot  FORTRAN  source  code.  For  this 
reason,  Systems  Group  personnel  more  typically  download  the  data  through  a  modem  and 
perform  custom  manipulations  and/or  presentations  of  the  data  using  desktop  computers. 

Fourth,  the  Plot  program  allows  no  more  than  1000  data  points  per  curve.  At  the 
maximum  sampling  rate  of  50  Hz,  this  is  only  20  seconds  of  data  from  one  transducer.  If  a 
larger  data  set  is  requested.  Plot  automatically  skips  intermediate  points,  and  effectively 
plots  the  data  at  a  lower  frequency  to  limit  the  number  of  data  points  plotted.  This 
sometimes  eliminates  fast,  but  important  test  events  from  presentation  on  the  plots. 
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A  description  of  how  these  deficiencies  will  be  resolved  by  the  Diagnostic  System 
is  included  in  Section  3.4  of  this  report. 

3.3.3  Data  Evaluation 

Evaluation  of  the  test  data  is  the  next  step  in  the  overall  diagnostic  process.  In 
general,  the  diagnostic  evaluations  rely  heavily  on  the  experience  and  ability  of  the 
individuals  performing  the  assessments.  Standardization  and  methodical  evaluation  of 
engine  performance  historical  trends  or  inviolate  specifications  are  not  emphasized.  As  a 
result,  a  reasonably  high  level  of  on-the-job  training  and  experience  is  required  for  the 
production  of  accurate  and  consistent  diagnostic  evaluations.  A  number  of  specific 
examples  from  our  observations  at  MSFC  made  this  point  clear. 

First,  very  little  automated  evaluation  of  the  data  is  currently  performed.  Direct, 
single  sensor  2  sigma,  green  run,  or  acceptance  specification  violations  are  not 
automatically  diagnosed  and  highlighted.  Instead,  manual  evaluation  of  the  test  data  reveals 
these  direct  violations. 

Second,  there  is  no  formal  catalog  of  historical  observations  of  the  engines  and  their 
data  signatures.  The  Systems  Group  has  recently  started  to  maintain  a  local  database  of 
observed  test  anomalies  and  a  verbal  description  of  the  supporting  evidence.  However, 
this  database  is  not  used  to  support  the  current  diagnostic  process  because  it  contains  a 
small  number  of  failures  with  no  unexplained  observations  from  previous  tests.  Presently, 
when  an  anomaly  or  observation  is  identified  in  the  current  test  data,  reference  to  previous 
test(s)  which  were  diagnosed  with  the  same  anomaly  is  accomplished  through  the 
individual's  recollection.  "I  remember  something  like  this  happened  about  nine  months 
ago,"  was  a  comment  that  started  a  search  back  through  the  test  summary  books  for  related 
historical  evidence  and  failure  signatures  while  we  were  at  MSFC. 

Third,  there  is  little  automated  reference  to  the  operating  history  of  individual 
engines  or  components.  Data  from  two  selected  tests  are  shown  on  most  of  the  standard 
plots  contained  in  the  data  book.  Frequent  changes  in  test  objectives  and  engine 
configurations  often  make  direct  comparison  of  current  test  data  with  previous  firings 
difficult.  Still,  important  historical  trends  in  the  operation  of  engine  components  is 
frequently  not  included  in  the  standard  data  package.  Drawing  upon  a  case  observed  at 
MSFC,  test  data  was  compiled  which  showed  that  over  the  three  previous  firings  of  an 
engine,  there  was  an  increasing  trend  in  the  cavity  pressure  outside  the  main  chamber  liner 
cooling  channels  (see  Figure  3-5).  This  is  a  strong  indication  of  a  leak  between  the  cooling 
channels  and  the  liner  closeout  The  plot  was  compiled  only  after  manual  evaluation  of  the 
data  trace  from  the  third  firing  and  it  revealed  an  unusually  high  pressure  in  the  cavity. 

The  operating  history  of  individual  engines  or  components  would  be  useful  to 
assess  the  operational  life  and  firing  history  of  engine  components.  The  number  of  starts 
and  seconds  on  bearing  sets  was  of  importance  in  trending  turbopump  bearing  wear  data. 
Currently  this  is  tracked  informally  by  the  Dynamics  group.  Another  example  was  a 
comment  regarding  data  presented  for  a  low  pressure  fuel  pump,  "Yes  -  but  doesn't  this 
pump  always  run  a  little  cool?"  This  started  a  long,  unresolved  discussion  about  the 
historical  operation  of  the  component.  It  was  obvious  that  there  was  no  single,  direct  way 
to  answer  this  question.  In  fact  current  procedures  would  require  queries  of  configuration 
data  from  TRACER  to  determine  which  tests  used  the  turbopump  in  question.  This  would 
then  be  followed  by  manual  review  of  the  data  from  these  tests. 
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3.3.4  Post  Test  Data  Review 


The  problems  observed  during  the  post  test  data  review  were  primarily  a  result  of 
the  deficiencies  discussed  in  preparation  and  evaluation  of  the  test  data.  Questions  about 
the  history  of  the  engine  components  came  up  frequently  and  the  discussions  often  ended 
without  clear  answers  to  the  original  query.  Automated  access  to  a  historical  test 
information  database  would  significantly  reduce  these  problems. 

3.3.5  Pre  Test  Data  Review 

The  problems  observed  during  this  part  of  the  diagnostic  process  are  primarily  the 
result  of  deficiencies  in  previous  steps.  The  major  difficulty  with  this  portion  of  the 
process  is  the  difficulty  personnel  at  MSFC  have  corroborating  information  presented  by 
Rocketdyne.  This  was  particularly  evident  in  the  discussion  of  DAR  reports.  DAR  reports 
show  the  component  history  in  terms  of  starts  and  seconds  of  hot  fire  life  experienced  on 
critical  components  for  the  upcoming  test. 


3 . 4  PROPOSED  APPROACH 

The  proposed  diagnostic  system  architecture  has  been  designed  with  consideration 
to  planned  MSFC  data  processing  capabilities.  The  software  will  combine  existing  (but 
currently  separate)  capabilities  with  new  data  analysis  and  expert  aided  diagnostics 
producing  a  fully  integrated  system  hosted  from  an  engineering  workstation.  We  have 
evaluated  the  user  benefits  associated  with  the  proposed  implementation  verifying  the 
payoffs  from  each  system  component.  We  have  developed  an  implementation  plan  for 
providing  the  workstation  package  to  MSFC  in  an  incremental  fashion  to  quickly  realize  a 
portion  of  the  benefits  and  provide  an  experience  base  which  will  help  in  completing  the 
balance  of  the  complex,  expert  system  implementation. 

3.4.1  System  Configuration 

The  proposed  workstation  architecture  will  build  upon  the  upgrades  to  the  existing 
data  processing  network  at  MSFC  (see  Figure  3-6).  MSFC  is  installing  a  VAX  6200 
system  linked  to  the  Perkin-Elmer  processor  (PE4)  over  a  high  speed  data  link.  Current 
MSFC  plans  call  for  the  new  VAX  system  to  support  multiple  users  at  terminals  throughout 
the  propulsion  laboratories.  The  VAX  users  will  be  able  to  generate  requests  to  the  PE-4 
ADP  staff  moving  test  data  from  tape  to  disk  or  to  automatically  move  test  data  from  optical 
media  to  high  speed  disk.  Data  will  be  extracted  from  the  PE-4  databases  and  moved  to 
local  VAX  storage  to  assist  in  engineering  analyses  performed  locally. 

The  proposed  software  architecture  will  use  a  portion  of  the  VAX  disk  storage 
system  for  a  local,  integrated  database  of  SSME  test  data  and  along  with  other  historical 
and  configuration  information.  These  integrated  databases  will  be  accessed  by  a  network 
of  data  analysis  workstations  which  will  be  interconnected  on  the  existing  LAN  and  use  the 
VAX  as  a  file  server.  To  workstation  users,  the  system  will  appear  as  a  distributed 
database  managed  by  the  INGRES  database  manager.  Access  times  for  the  workstation 
users  should  be  excellent  based  on  the  high  performance  of  the  VAX  disk  drives  and 
DECNET  LAN.  Thus,  the  actual  data  residency  will  be  invisible  to  the  workstation  users. 
The  local  workstation  disks  will  be  sufficient  for  temporary  and  user  generated  data  storage 
along  with  storage  of  local  software  applications  as  required. 
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The  workstation  hardware  will  be  based  on  a  RISC  implementation.  The 
workstation  will  have  integer  performance  in  excess  of  12  million  instructions  per  second 
(MIPS)  and  floating  point  performance  in  excess  of  one  million  double  precision  operations 
per  second  (LINPACK).  It  will  provide  a  minimum  of  8  MBytes  of  RAM  and  a  64  KByte 
cache  to  increase  throughput.  The  workstation  connection  to  the  DECNET/Ethemet  LAN 
will  operate  at  10  Mbits/second.  The  local  mass  storage  will  be  in  excess  of  100  MBytes  of 
SCSI  hard  disk  storage  with  22  milliseconds  average  seek  time  and  1.2  MBytes/second 
transfer  rate.  There  will  be  a  large,  color  graphics  monitor  with  optical  mouse.  The 
operating  system  will  be  a  UNIX-based  multi-tasking  window  system  with  pull-down 
menus  enhancing  the  user  interface  and  reduce  training  requirements. 

Implementation  of  the  full  expert-aided  diagnostic  system  will  require  four  to  eight 
workstations  networked  into  the  VAX  file  server.  The  current  architecture  being 
implemented  by  MSFC  will  permit  this  without  difficulty. 

3.4.2  Proposed.  Software  Functionality 

3 . 4 . 2 . 1  Integrated  Database  Environment 

3.4.2. 1.1  Maintain  SS ME  Test  Database 

These  applications  will  transfer  SSME  test  data  from  the  PE4  computer  into  the  file 
server  database.  The  application  will  allow  sufficient  flexibility  to  transfer  all  or  part  of  the 
test  time  and  all  or  pan  of  the  engine's  sensor  set  at  various  sampling  rates. 

Requests  to  the  PE4  operators  to  move  the  test  database  from  tape  or  from  optical 
storage  will  be  created  as  required.  The  data  will  be  transferred  over  the  high  speed  data 
link  using  the  file  transfer  protocol  best  suited  for  the  data,  e.g.,  TCP/IP.  File 
compression/decompression  will  be  performed  if  beneficial  to  the  overall  efficiency  of  the 
process. 

Data  will  be  loaded  into  the  integrated  database  on  the  file  server  and  indices  created 
for  access.  These  applications  will  allow  the  user  to  manage  test  data  stored  on  the  file 
server  including  record  display,  deletion,  editing,  etc. 

3.4.2. 1 .2  Maintain  Anomaly  and  Incident  Reports 

Applications  will  be  provided  to  store  anomaly  data  derived  from  previous  test 
reviews  into  an  integrated  database.  This  information  will  include  narratives  describing 
anomaly  characteristics,  causes  determined,  and  identifying  sensors.  In  addition,  data 
traces  showing  the  anomaly  signature  may  be  incorporated  into  the  data  record.  The 
anomaly  will  be  represented  with  a  group  of  sample  data  traces  from  involved  sensors  or. 
more  generally,  using  feature  descriptors  such  as  slope,  level  and  duration  of  the  response. 

Records  can  be  entered,  deleted,  edited  and/or  displayed.  Data  indices  will  include 
test  number,  date  and  affected  engine  components. 

3. 4. 2. 1.3  Maintain  Two-Sigma  Database 

Applications  will  allow  storage  and  retrieval  of  two-sigma  data  bands  for  start-up, 
mainstage  and  shutdown.  The  two-sigma  bands  will  be  available  for  plotting  and 
comparison  with  actual  test  data.  The  bands  will  be  updated  with  selected  test  runs  on  user 
request.  New  bands  may  be  created  for  new  or  varied  test  scenarios.  Applications  will  be 


provided  to  examine  ensembles  of  test  runs  and  extract  the  two-sigma  data  bands  so  that 
customized  bands  can  be  created  for  specific  SSME  configurations. 

3 . 4 . 2 . 1 . 4  Maintain  Configuration  Data 

Applications  will  enable  tracking  of  the  major  SSME  components'  operating 
history.  Since  parts  tracking  is  performed  by  the  TRACER  program,  this  application  will 
principally  download  configuration  data  to  the  file  server  and  provide  a  subset  of  the 
TRACER  records  for  correlation  during  test  data  analysis. 

In  addition,  an  on-line  query  generator  will  be  provided  to  automatically  generate  a 
TRACER  data  extraction  for  specific  configuration  requests.  For  example,  if  the 
installation  history  of  a  particular  HPOP  was  required,  the  user  would  complete  the  several 
entries  on  a  workstation  form.  The  application  would  connect  to  the  TRACER  mainframe 
at  Canoga  Park,  run  the  required  job  stream,  recover  the  data  and  incorporate  it  into  the 
database  for  inspection  and  correlation  with  test  data. 

3.4.2. 1.5  Maintain  Specification  Data 

Data  on  specification  requirements  will  be  maintained  to  aid  in  the  automated 
evaluation  of  acceptance  test  and  green  run  data.  Data  will  reflect  the  minimum  and 
maximum  acceptable  sensor  values  for  all  engine  measurements  called  out  in  the  applicable 
specifications.  Storage  of  these  values  in  the  integrated  database  will  permit  automatic 
updates  to  the  evaluation  criteria  if  engine  requirements  or  design  changes  affect  the 
specifications. 

Records  can  be  entered,  deleted,  edited,  and/or  displayed.  The  specification  data 
will  be  indexed  on  specification  type,  operating  phase  and  sensor  identifier. 

3 . 4 . 2 . 1 . 6  Maintain  Inspection  Data 

Data  from  each  manual  inspection  of  the  engine  are  now  maintained  by  the  Systems 
Group.  The  data  provides  added  evidence  to  evaluate  hypotheses  about  observed  test 
events.  Inspection  repons  from  previous  firings  of  specific  engine  components  are  also 
used  during  post-test  data  reviews.  Storage  of  these  inspection  repons  in  the  integrated 
database  will  be  helpful  in  supporting  expert-aided  automated  diagnostics. 

Records  can  be  entered,  deleted,  edited,  and/or  displayed.  The  inspection  data  may 
be  manually  or  automatically  queried  for  specific  test  numbers,  dates,  LRU  numbers,  or  by 
the  identification  of  certain  test  events  in  the  data 

3. 4. 2. 2  Computer  Aided  Engineering  (CAE)  Environment 

3. 4. 2. 2.1  Plotting  Applications 

A  comprehensive  color  data  graphing  application  will  allow  test  engineers  to  plot 
test  information  in  a  variety  of  formats.  Test  to  test  comparison,  multi -variable  plots,  two- 
sigma  overplots  and  other  analysis  requirements  will  be  supported  by  the  application  in 
conjunction  with  the  databases. 

These  applications  will  allow  specific  plots  to  be  stored  in  the  database.  There  will 
be  an  extensive  range  of  standard  chart  formats  including  multi-plot,  multi-line,  bar,  pie,  3- 
D,  etc.  Plot  parameters  or  templates  can  be  stored  so  that  standard  plot  reports  can  be 
designed  and  created  automatically  when  test  data  becomes  available. 
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The  plot  applications  will  be  based  on  third  party  graphics  and  data  analysis 
packages  suitable  for  the  workstation.  Over  forty  such  packages  were  reviewed  in  Task  2 
of  this  study.  Section  4.3  of  this  report  discusses  this  review  ano  recommends  seven 
candidates  for  further  evaluation. 

Minimal  computer  programming  is  required  and  the  interface  will  use  multiple 
windows  with  a  mouse.  Zooming  will  dynamically  rescale  local  areas  of  the  plot  for  closer 
examination  under  mouse  control. 

3. 4. 2. 2. 2  Data  Processing/Statistic  Applications 

A  general  purpose  computer-aided  engineering  (CAE)  function  will  allow  direct 
manipulation  of  data  vectors  by  the  user  through  non-programmatic  mathematical 
expressions.  The  CAE  function  will  support  all  types  of  signal  processing  and  analysis 
techniques  including  digital  filters,  FFT,  statistical  filters  (e.g.,  maximum  likelihood, 
Kalman,  etc.),  dynamic  modelling,  regressions,  ARMA,  etc.  Free  form  analyses  by  the 
user  will  be  provided  using  direct  mathematical  expressions  or  predefined  functions  that 
operate  on  the  data.  Results  will  be  expressed  in  a  tabular  or  graphical  output,  or 
maintained  as  intermediate  values  in  a  multi-step  a-  .uys's  These  free  form  analyses  will 
provide  an  additional  basis  for  knowledge  rapture  in  the  expert  application. 

3 . 4 . 2 . 2 . 3  Report  Generation  Application 

An  application  will  provide  standard  report  lormats  which  integrate  graphical  data 
presentations  with  text  from  related  databases  or  manual  input.  These  reports  can  be 
automatically  produced  when  a  specific  set  of  flight  data  are  studied  for  test  evaluation  and 
health  assessment.  The  reports  will  be  user  generated  and  easily  modified  to  support 
unique  investigations. 

3. 4. 2. 3  Special  Applications 

3. 4. 2. 3.1  Sensor  Validation 

An  application  (developed  under  a  separate  task)  will  provide  sensor  validation. 
Test  data  sequences  will  provide  the  input  to  the  program  determining  indications  of  faulty 
sensors.  Sensor  faults  such  as  bias  shift,  scale  factor  error,  noise,  and  environment-caused 
errors  will  be  addressed  by  the  package.  In  addition  to  the  error  indications,  an  estimate  of 
the  corrected  sensor  readings  will  be  produced. 

3.4.2. 3.2  Start/Main  Stage/Shutdown  Analysis 

The  performance  of  the  engine  against  the  applicable  ICD,  Green  Run,  or 
Acceptance  Specifications  will  be  evaluated  automatically.  Exceptions  to  performance  will 
be  generated  and  form  the  basis  for  diagnostic  analysis  by  the  users  and  the  expert  aided 
system. 

3.4.2. 3. 3  General  (2-Sigma/Features)  Exception  Analysis 

An  application  will  automatically  screen  data  sequences  against  two-sigma  bands 
established  for  the  specific  test  scenario.  Exceptions  will  be  generated  to  initiate  diagnostic 
analysis  and  provide  supporting  information  to  the  expert  aided  data  analysis  applications. 
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An  application  will  automatically  screen  test  phase  data  against  feature  descriptors 
for  normal  and  anomalous  behavior.  SSME  faults  exist  which  do  not  cause  exceedances  of 
2-sigma  bands,  but  which  exhibit  either  unusual  or  identified  abnormal  behavior.  An 
example  of  this  is  fuel  side  oscillations  which  occasionally  occur  during  shutdown. 
Exceptions  to  either  two-sigma  or  normal  feature  definitions  will  be  logged  and  recorded 
against  the  test  sequences  in  question.  Troubleshooting  applications  will  use  these 
indicators  and  the  established  diagnostic  rule  base  to  correlate  identified  exceptions  with 
known  failure  modes. 

3 . 4 . 2 . 3 . 4  Power  Balance  Model 

The  power  balance  model  will  be  integrated  into  the  test  analysis  environment. 
Averaged  test  data  will  be  created  for  inputs  and  outputs  relating  to  Kf s,  etc.,  and  will  be 
incorporated  into  the  test  phase  reports.  The  model  will  also  be  used  for  2-sigma  steady- 
state  detection  during  specific  test  phases.  Additional  applications  and  special 
investigations  will  also  be  supported  within  the  workstation  environment. 

3 . 4 . 2 . 4  Expert  Aided  Diagnostics 

3. 4. 2. 4. 1  Maintain  Diagnostic  Rules  (Anomaly  Associations) 

Diagnostic  rules  will  assist  the  analyst  in  correlating  observed  indicators  (data 
exceptions)  with  one  or  more  previously  identified  anomalies.  The  anomaly  database  will 
be  built  from  test  experience  and  history.  The  inference  process  which  links  specific  data 
exceptions  with  the  abnormalities  will  be  captured  in  the  rule  base.  This  function  will 
capture  the  knowledge  linking  the  exceptions  with  faults.  The  representation  selected  will 
recognize  the  attributes  of  the  abnormality  and  search  for  matching  indications  in  data. 
After  analysis  of  the  exception,  the  knowledge  base  will  be  updated  automatically  (under 
manual  control)  to  capture  the  reasoning  and  outcome  of  the  analysis  so  that  it  can  be 
applied  to  future  occurrences. 

3 . 4 . 2 . 4 . 2  Perform  Aided  Diagnoses 

This  application  will  lead  the  user  through  a  structured  analysis  of  one  or  more 
abnormal  indications.  The  inference  structure  represented  in  the  knowledge  base  will  be 
used  as  the  basis  for  the  analysis;  however,  at  any  time,  the  user  can  examine  specific  data 
on  the  current  test  and  from  prior  occurrences  of  suspected  anomalies. 

The  user's  path  through  the  inference  process  will  be  automatically  captured  by  the 
system  using  the  transaction  log.  This  log  will  form  the  basis  for  rule-base  updates  using 
the  expert  system's  knowledge  maintenance  tools.  The  application  will  allow  partial 
diagnostics  of  multiple  exceptions  so  that  the  user  can  combine  conclusions  between 
exceptions.  The  linking  of  multiple  diagnostic  goals  is  an  inherent  feature  of  the 
NEXPERT  Object  shell  selected  for  the  application. 

3. 4. 2. 4. 3  Advanced  Diagnostic  Applications 

Advanced  applications  will  be  integrated  into  the  workstation  data  environment  to 
support  special  investigations  and  advanced  diagnostic  development.  The  intent  of  the 
computing  environment  is  to  provide  the  flexibility  to  incorporate  advancing  capabilities 
rapidly  and  cheaply  in  an  incremental  manner.  Advanced  features  may  include  deep¬ 
reasoning  diagnostic  systems  which  incorporate  physical  models  of  SSME  faults  and 
automatic  knowledge  generation/maintenance  tools  applicable  to  the  problem. 


24 


3.4.3  Application  Users  and  Benefits 


We  have  partitioned  the  system  into  applications  which  support  the  various  data 
users.  For  each  application,  there  are  one  or  more  benefits  that  the  new  workstation 
implementation  will  provide.  In  Figure  3-7,  we  have  compiled  a  list  of  the  benefits  of  each 
application  area  and  associated  them  with  the  user  groups  deriving  the  benefit.  It  is  clear 
from  the  figure  that  there  are  several  applications  which  will  immediately  benefit  several 
user  groups  and  that  benefits  will  be  provided  at  each  level  of  system  implementation. 
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APPLICATION  |  FUNCTIONALITY  L  BENEFITS 
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FIGURE  3-7  Post-Fire  Health  Assessment  Workstation  User  Benefits 
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FIGURE  3-7  Post-Fire  Health  Assessment  Workstation  User  Benefits  (Cont'd) 


APPLICATION  I  FUNCTIONALITY  |  BENEFITS 
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FIGURE  3-7  Post-Fire  Health  Assessment  Workstation  User  Benefits  (Cont'd) 


APPLICATION  I  FUNCTIONALITY  I  BENEFITS 


FIGURE  3-7  Post-Fire  Health  Assessment  Workstation  User  Benefits  (Cont’d) 


This  page  left  intentionally  blank. 
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4.0  TASK  2  -  SYSTEM  DEFINITION 


4 . 1  HIGH  LEVEL  ORGANIZATION 

This  section  describes  the  software  required  for  an  automated  system  to  perform 
post  fire  diagnosis  and  health  assessment  of  the  SSME.  The  system  is  designed  to  meet  the 
user  requirements  and  provide  the  benefits  discussed  in  section  3.0  using  a  distributed 
architecture  approach. 

Figure  4-1  maps  the  logical  organization  of  the  system.  The  system  requires 
database  management,  CAE  capabilities  for  data  manipulation,  presentation  and  plotting, 
special  applications  for  specific  data  evaluations,  and  expert  systems  (under  the  Nexpert 
Object  Expert  System  Shell).  Procedural  portions  of  the  code  will  be  written  in  C. 


Anomalies 

Plotting 

Sensor  Validation 

Feature  Idemitcatlon 

Security 

2 -Sigma  Data 

Statistical  Analysis 

Startup  Analysts 

Features_to_  Anomalies 

install 

Configurations 

Inspedxtns 

Tael  Data 

Spadix*  ions 

Report  Generation 

Signal  Processing 

Main  Stage  Analysis 

Shutdown  Analysis 

2  Sigma  Exceptions 

Green  Run  Analyse 

Power  Balance  Model 

Transient  Analyse 

Expen-Aided 

Diagnostics 

Advanced  Diagnostics 

Document 

FIGURE  4-1  Overall  Organization  of  Diagnostic  System 

The  executive  program  provides  the  primary  user  interface  for  these  system  and  will 
reside  on  a  Sun  workstation.  The  workstation  will  in  turn  generate  requests  for  data  and/or 
calculations  on  one  or  more  of  the  other  systems  (VAX,  PE-4,  and  IBM)  as  required  using 
the  existing  LAN  at  MSFC.  These  requests  and  the  background  processing  will  be  made 
transparent  to  the  user. 

Data  used  by  the  system  to  make  diagnostic  evaluations  will  be  stored  on  the  VAX 
6320  at  MSFC  under  the  Ingres  relational  database  management  system.  Specific  database 
structures  and  attributes  are  described  in  section  4.2  of  this  report. 

Presentation  and  analysis  of  data  will  be  accomplished  with  the  aid  of  a  commercial 
analysis,  graphics  and  statistics  package.  Over  forty  commercial  packages  were  examined 
during  the  course  of  this  study  and  a  list  of  eight  packages  has  been  recommended  for 
further  evaluation.  Section  4.3  of  this  report  discusses  both  the  use  of  CAE  packages 
within  this  diagnostic  system  and  examines  the  capabilities  of  the  packages. 

Diagnostic  evaluation  and  analysis  of  hot  fire  data  is  conducted  in  two  areas  of  the 
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system.  The  first  of  these  is  called  the  special  application  module.  The  second  is  called  the 
expert-aided  diagnostic  module.  Classification  of  the  diagnostic  applications  into  one  of 
these  two  areas  is  preliminary.  For  example,  there  is  some  merit  in  classifying  the  program 
which  analyzes  hot  fire  data  against  the  green  run  requirements  as  an  expert  system 
diagnostic.  However,  we  have  chosen  to  classify  it  as  a  special  application  because  the 
green  run  evaluation  criteria  is  relatively  straight-forward  and  does  not  require  heuristic 
reasoning  or  interpretation  based  on  experience. 

The  special  applications  module,  then,  is  a  collection  of  diagnostic  routines  that  are 
primarily  procedural  in  nature.  These  evaluations  are  currently  performed  in  a  relatively 
structured  and  repeatable  manner  during  the  course  of  the  data  analysis.  Some  of  these 
special  applications  exist  as  stand-alone  applications  on  MSFC  processors  (the  PE-4,  IBM 
mainframe  or  IBM-PC)  and  are  currently  supporting  the  diagnostic  activity.  Development 
efforts  will  be  concentrated  on  making  these  individual  programs  work  together  within  the 
integrated  diagnostic  system.  Each  special  application  is  discussed  in  more  detail  in  Section 
4.4. 


The  expert-aided  diagnostics  module  will  use  expert  systems  technology  based  on 
the  NTEXPERT  Object  shell  to  emulate  the  heuristic  evaluations  and  health  assessments 
currently  performed  by  experienced  engineers.  A  knowledge  base  will  be  constructed  to 
automatically  identify  features  (with  a  confidence  factor)  in  the  hot  fire  data.  These  features 
and  confidence  factors  along  with  other  information  concerning  the  test,  engine 
configuration,  inspection  reports,  etc.  will  then  be  used  to  diagnose  the  cause  of  the 
anomalous  behavior.  Section  4.5  presents  the  applications  and  knowledge  bases  required 
for  development  of  these  capabilities. 


4 . 2  INTEGRATED  DATABASE 

4.2.1  Applicatipn.Lisi.and  Qmpuis 

The  integrated  database  provides  the  foundation  for  the  diagnostic  system.  The 
database  consolidates  information  from  sources  which  are  currently  disconnected.  The 
purpose  of  the  integrated  database  is  to  provide  a  consistent  format  and  a  universally 
available  platform  to  all  of  the  data  which  is  relevant  to  the  diagnostic  process. 

Six  general  categories  of  data  were  identified  as  important  and  useful  in  the 
diagnostic  process.  These  categories  are: 

a.  Engine  Build  Configurations  &  Operating  Profiles  (i.e.,  component 
history); 

b .  Identified  Operating  Anomalies; 

c.  Hardware  Inspection  Reports; 

d.  Statistical  (2-Sigma)  Norms; 

e.  Specification  Requirements;  and 

f.  Test  or  Flight  Measurements  (i.e.,  CADS,  Facility,  and  Analog 
data). 

This  data  originates  from  a  variety  of  locales.  The  current  data  storage  formats 
include  from  an  IBM  DB2  database,  IBM-PC  Symphony  file  to  hand-written  reports.  The 
source  of  each  of  these  data  types  are  listed  in  Figure  4-2. 
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FIGURE  4*2  The  Integrated  Database  Consolidates  Diagnostic 
Information  from  Various  Sources 
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FIGURE  4-3  Summary  of  Database  Applications 
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The  integrated  database  will  be  hosted  on  a  VAX  6320  at  MSFC  under  the  Ingres 
database  management  system  (dBMS).  Maintenance  of  the  data  in  the  integrated  database 
will  be  accomplished  by  a  combination  of  Ingres  capabilities  and  procedural  programs. 
Manual  updates  to  the  contents  of  the  data  files  will  be  possible  through  Ingres.  Automated 
updates  of  the  configuration,  anomaly,  sigma  and  test  data  files  will  be  accomplished  via 
procedural  programs  working  in  conjunction  with  Ingres. 

Standard  reports  on  the  contents  of  individual  data  files  in  the  integrated  database 
will  be  provided  under  Ingres.  On-line  reports  which  involve  joins  of  data  from  various 
data  categories  and  files  will  be  provided  through  Ingres  in  response  to  user-defined 
queries. 

Figure  4-3  shows  the  applications  which  will  be  provided  to  maintain  and  report  the 
contents  of  the  integrated  database. 

The  physical  output  of  the  integrated  database  will  be  reports  which  show  the 
current  contents  of  the  database  files.  These  are  the  standard  repons  listed  in  Figure  4-2. 
An  example  of  a  standard  report  is  shown  in  Figure  4-4. 


DATABASE  REPORT  FOR  FILE:  Sigma’Values 


DATE:31  Aug  1990 


Operating 

Power 

PID 

Sensor 

Mean 

One  Sigma 

Phase 

Level 

Number 

Description 

Value 

Value 

Mainstage 

100 

163 

MCC  Pc 

3006.25 

1.31 

Maintstage 

100 

203 

LPFP  DS  P 

224.80 

12.92 

Mainstage 

100 

225 

LPFP  DS  T 

42.62 

0.48 

Mainstage 

100 

152 

HPFP  DS  P 

5878.55 

36.03 

Mainstage 

100 

231 

HPFTT  A 

1662.71 

59.41 

Mainstage 

100 

232 

HPFTTB 

1678.84 

45.95 

Mainstage 

100 

261 

HPFTP  SPD 

34389.38 

238.97 

Mainstage 

100 

209 

LPOP  DS  P 

352.40 

19.10 

Mainstage 

• 

• 

• 

100 

• 

• 

• 

190 

• 

• 

• 

HPOP  DS  P 

• 

• 

• 

3883.72 

• 

• 

• 

23.92 

FIGURE  4-4  Typical  Report  of  Database  Contents 


4.2.2  Data  Smictures 


Preliminary  Ingres  file  structures  were  developed  for  each  of  the  major  data 
categories.  These  file  structures  are  shown  in  Table  4-1,  and  include  the  field  name,  data 
type  and  field  length.  Four  data  types  were  used:  character,  integer,  floating  point,  and 
note.  The  length  of  character,  integer,  and  floating  point  fields  are  shown  in  Table  4-1. 
The  note  data  type  is  a  field  of  dynamically  variable  length  which  can  hold  text  or  graphical 
information. 
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DATABASE:  CONFIG 


File:  Hardware 

TESTNO,  I,  6 
TEST'D  ATE,  C,  6 
ENGINE,  C,  6 
HPOP'UN,  C,  8 
HPFP'UN,  C,  8 
LPOP'UN,  C,  8 
LPFP'UN,  C,  8 
HPOP'SN,  C,  8 
HPFP'SN,  C,  8 
LPOP'SN,  C,  8 
LPFP'SN,  C,  8 
PWR'HEAD,  C,  6 
MAIN'INJ,  C,  6 
MCC,  C,  6 
NOZZLE,  C,  6 
CNTRLR,  C,  6 
HPOP’IMP,  C,  10 


File:  Test’Profile 

TESTNO,  I,  6 
STARTTIME,  F,  6 
ENDTIME,  F,  6 
POWER-LEVEL,  F,  6 


DATABASE.  ANOMALY 


File:  Anomaly'List 

TESTNO,  I,  6 
ANOMALYTIME,  F,  6 
ANOMALY-COMP-NAME,  C,  6 
RID-NO,  I,  6 
MR-NO,  I,  6 
UCR'NO,  I,  6 

ANOMALY'DESCRIP,  NOTE 
ANOMALY’SIGNATURE,  NOTE 
ANOMALY'RESPONSE,  NOTE 


TABLE  4-1  File  Structures 


36 


DATABASE:  INSPECTIONS 

File:  HpopTRpt 

ENGINE, 1, 4 
TESTNO, 1, 6 
INSP'DATE,I,6 

ENGINEER, C, 35  'inspection  engineer 

TT’BRK,F,6  'breakaway  torque 

TTPRM,F,6  'running  torque 

TT'COM.NOTE  torque  comments 

SM'OVER ALL, NOTE  turbine  inlet  sheetmetal  appearance 

SM'STRUT'LEAD.NOTE 

SM'STRUTSIDE.NOTE 

SM'STRUTTR  AIL, NOTE 

SM'STRUT'WELDS.NOTE 

SVNOZ'OVER  ALL,  NOTE 

Sl’NOZ'IO'SHROUD.NOTE 

SI  'NOZ'VANE'LEAD.NOTE 

SI'NOZ'VANE'AIR.NOTE 

Si  ’NOZ’VANE’TR  AIL, NOTE 

SI  'TURB'BLD'LEAD.NOTE 

SI'TURB'BLD'AIR.NOTE 

SI  'TURB'BLDTSHROUD.NOTE 

SI  'TURB'BLD'O'SHROUD.NOTE 

BRG'3'CAGt,NOTE 

BRG’3'R  ACE, NOTE 

BRG'3'BALLS,NOTE 

BRG'3'PHOTOS,C,1 

MAIN'IMP.NOTE 

TURN'VANE.NOTE 

PBP'INLET.NOTE 

PBP'IMP'BOLT'LOCK,NOTE 

PRILOX'SL'LEAK'CHK'DATE.C.6 

PRI'LOX'SL'LEAK’RATE,F,6 

PRI'TURB'SL'LEAK'CHK’DATE,C,6 

PRI'TURB'SL'LEAK'RATE,F,6 

TEST'PLATE'THICKNESS,F,6 

BASE'MEASURE,F,6 

MEAS'ROTOR'END'PI  ,F,6 

MEAS'ROTOR'END'P2,F,6 

MEAS'ROTOR'END'P3,F,6 

MEAS'ROTOR'END'P4,F,6 

S2'TURB'BLD,NOTE 

G2'SL,NOTE 

G3'SL,NuTE 

_ ER.NQTE _ '  eccentric  rings 

TABLE  4-1  File  Structures  (Cont'd) 
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File:  LpopTRpt 

ENGINE, 1.4 

TEST‘NO,l,6 

INSP'DATE.1,6 

ENGINEER, C, 35 

TT’BRK,F,6 

TTPRM,F,6 

TTCOM.NOTE 


File:  HpfpTRpt 

ENGINE, 1, 4 
TESTNO, 1, 6 
INSP'DATE.1,6 
ENGINEER, C, 35 
TTBRK,F,6 
TT'PRM,F,6 
TT’COM.NOTE 
SHAFTDIM,F,6 
SHAFTTVL.F.6 
B'MARK'ALIGN.NOTE 
SM'OVERALL.NOTE  lurbine  inlet  sheetmetal  appearance 

SM'STRUT'LEAD.NOTE 
SM'STRUTSIDE.NOTE 
SM'STRUTTRAIL.NOTE 
SM'STRUT'WELDS.NOTE 
KAISER'NUT.NOTE 
THERM'SHLD.NOTE 
Sl'NOZ'OVERALL.NOTE 
SI  'NOZ'IO'SHROUD.NOTE 
SI  'NOZ'VANE'LEAD.NOTE 
SI  'NOZ'VAN  E' Al  R  .NOTE 
Si  'NOZ'VANE'TRAIL.NOTE 
TURB'TIP'SL'OVERALL.NOTE 
TURB'TIP'SL'FILLER.NOTE 
TURB'TIP'SL'JNT.NOTE 
Si  'TURB'BLD'LEAD.NOTE 
STTURB'BLD'AIR.NOTE 
SI  'TURB'BLD'PLAT.NOTE 
SI  TURB'BLD'TRAIL.NOTE 
SI  'TURB'BLD'D  AMP, NOTE 
PLATFORM'SL.NOTE 
TURB'DSCH'SM'OVER  ALL, NOTE 
TURB'DSCH'TA'MANI.NOTE 
TURB'DSCH’O’BELLOWS.NOTE 
S2'TURB'BLDTURB'DSCH,NOTE 
S2'TURB'BLD’D  AMP, NOTE 
BAL'PIST'GAP,F,6 
SHIM'THICKNESS,  F,  6 
BRG'INLET-COOL-HOLES.NOTE 
BRG'DSCH'COOL-HOLES.NOTE 
PUMP'END'TURB-END'SL.NOTE 
G6'FLANGE,NOTE 
SITIP-SL'RETAIN-LUG.NOTE 

S2'TIP'SL,NOTE _ _ 

TABLE  4-1  File  Structures  (Cont’d) 


'inspection  engineer 


"inspection  engineer 
"breakaway  torque 
"running  torque 

torque  comments 
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File:  LpfpTRpt 


ENGINE,  1, 4 

TEST’NO.1,6 

INSP'DATE,I,6 

ENGINEER, C, 35 

TTBRK,F,6 

TTPRM,F,6 

TTCOM.NOTE 


File:  CdevTRpt 

ENGINE, 1, 4 
TESTNO, 1, 6 
INSP’DATE,I,6 
ENGINEER, C, 35 
SPARK’1  .NOTE 
SPARK'2, NOTE 
ASI’OX'ORI.NOTE 
ASI'FU'ORI-NOTE 
ASI'CHAMBER.NOTE 
INJ'REM  ARKS, NOTE 
MCCROUGH-BEFORE'TYP,C,15 
MCC-ROUGH'BEFORE-MAX,C,15 
MCC-ROUGH'BEFORE'3UP,C,15 
MCC-ROUGH-BEFORE-4DN,C,15 
MCC'REM  ARKS, NOTE 
NOZ'REM  ARKS, NOTE 
TPS'REM  ARKS, NOTE 
FPB'BAFFLE'1  .NOTE 
FPB.BAFFLE-2.NOTE 
FPB, BAFFLE-3, NOTE 
FPB‘SPARK'1  .NOTE 
FPB'SPARK"2,NOTE 
FPB'OX'ORI.NOTE 
FPB'FU'ORI.NOTE 
FPB'CC.NOTE 
FPB'REM  ARKS, NOTE 
OPB'BAFFLE’1  .NOTE 
OPB, BAFFLE-2, NOTE 
OPB, BAFFLE-3, NOTE 
OPB'SPARK'I  .NOTE 
OPB-SPARK-2.NOTE 
OPB'OX'ORI.NOTE 
OPB'FLTORI.NOTE 
OPB'CC.NOTE 

OPB'REMARKS.NOTE _ 

TABLE  4-1  File  Structures  (Cont'd) 


'inspection  engineer 
"breakaway  torque 
'running  torque 

torque  comments 


'inspection  engineer 
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DATABASE:  SIGMAS 

Datafile:  Sigma'Tests 

TESTNO,  1,6 
ENGINE'PHASE.C.I 
POWER’LEVEL,  F,  6 
PID'NO,l,6 

MEANTEST'VALUE.F.6 


Datafile:  Sigma'Values 

ENGINE'PHASE,  C,  1 
POWER'LEVEL,  F,  6 
PID'NO,  1.6 
MEAN'VALUE,  F,  6 
ONE'SIGMA'VALUE,  F,  6 


DATABASE:  SPECIFICATIONS 
Datafile:  Specifications 


SPECTYPE.C.1 

PID'NO, 1, 6 

ENGINE'PHASE.C.I 

START'TIME.F.6 

ENDTIME.F.6 

HIGH'LIMIT,F.6 

LOW'LIMIT.F.6 

TREND'LIMIT,F.6 

VIOLATION'DESCRIPTION.NOTE 


'A  (Acceptance),  I  (ICD),  G  (Green  Run) 
'P(Pre-start),  S(Start),  M(Mainstage),  D(Shutdown) 


'In  engineering  units/sec 


TABLE  4-1  File  Structures  (Cont'd) 
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4.2.3  Database  HTPO  Analysis 


As  discussed  in  Section  4.2.1,  applications  are  required  to  maintain  and  report  on 
the  contents  of  the  integrated  database.  A  summary  of  the  required  applications  was  shown 
in  Figure  4-3.  This  section  defines  each  of  these  applications  through  the  use  of  a 
Hierarchical  Input  Process  Output  (HIPO)  analysis.  Shown  in  these  HIPO  analyses  are  the 
input  into  each  application,  a  description  of  the  processing  done  within  the  application,  and 
the  output  of  each  application. 


4.2.3. 1  Configuration  Data 

4 . 2 . 3 . 1 . 1  Automated  Updates  of  Configuration  Data 


4. 2. 3. 1.1.1 

A. 

B. 

C. 

D. 

4.2.3. 1.1.2 

A. 

B. 


Input 

Configuration  and  test'profile  datafiles. 

User  request  to  automatically  update  the  Configuration  database  for 
specified  test  number(s). 

Tracer  hardware  configuration  files. 

SSME  Test  Data  for  selected  test  numbers). 

Process 

Open  communication  link  to  RKDN  Tracer  Program. 

Retrieve  test  number,  date,  and  LRU  identifiers  matching  user  request. 
Format  data. 


C .  Transfer  update  file  to  V  AX. 

D.  For  each  record  in  update  file. 

Search  for  match  in  configuration  file.  (Key:  test’no). 

If  match 

THEN  Replace  existing  record. 

ELSE  Append  new  record 

E.  Open  communication  link  to  PE-4. 

F .  Locate  SSME  test  data  for  the  specified  test(s). 

G .  For  each  measurement  point  in  test  data  file(s) 

( 1 )  Calculate  power  level,  rounded  to  nearest  percent 

(2)  Test  against  previous  power  level  calculation 

If  equal 

THEN  do  nothing 
ELSE 

i.  add  end  time  to  open  test’profile  record 

ii.  construct  new  record  with  start  time  for 
test’profile 
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H .  Load  resulting  file  into  Test'Profile  datafile. 

(1)  Append  new  records  (key:  test’no) 

(2)  Replace  existing  records  for  key  match 

4. 2. 3. 1.1. 3  Output 

Automatically  updated  Configuration  and  test’profile  datafiles  for  specified  test 
number(s). 

4.2.3. 1.2  Manual  Updates  of  Configuration  Data 

4. 2. 3. 1.2.1  Input 

A.  Configuration  and  test'profile  data  files. 

B.  User  request  to  manually  update  data 

4.2.3. 1.2.2  Process 

A.  User  enters  edit  mode. 

B .  Records  appear  from  configuration  and  test'profile  data  files  indexed  by 
test'no.  User  has  keyboard  control  to 

Add  —  new  records 
Delete  --  a  character,  or  record 
Change  -  contents  of  any  field 
Save  -  work  to  date 
Abort  -  edits  this  session 

C .  Upon  exit  of  edit  mode,  edited  records  are  saved. 

D.  Reindex  edited  data  files. 

4. 2. 3. 1.2. 3  Output 

Manually  edited  configuration  and  test'profile  datafiles. 

4 . 2 . 3 . 1 . 3  Standard  Reports  of  Configuration 

4. 2. 3. 1.3.1  Input 

A.  Configuration  and  test'profile  data  files. 

B .  User  request  for  standard  report. 

C.  User  designation  of  report  sort  order  and  search  condition(s). 

4.2.3. 1.3.2  Process 

A.  Open  configuration  and  test'profile  data  files. 

B .  Construct  report  based  on  specified  sort  order  and  search  condition. 

C.  Display  results  on  screen  or  send  to  printer  as  requested. 
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4. 2. 3. 1.3. 3  Output 


4.2.3. 

4.2.3. 

4.2.3. 


4.2.3 


4.2.3 

4.2.3 

4.2.3 


4.2.3 


Screen  display  or  printed  report  shown  in  Figure  4-4. 

2  Anomalies  Data 

2. 1  Automated  Updates  of  Anomalies  Data 

2.1.1  Input 

A .  Anomal  y  datafile . 

B .  Identified  test  anomaly  from  Expert-Aided  Diagnostics  Applications. 

C .  User  permission  to  record  identified  anomaly. 

.2.1.2  Process 

A.  Open  Anomaly  Datafile. 

B .  Add  new  record  with  test'no,  anomaly'time,  anomaly’comp'name,  anomaly 
description  (text),  and  anomaly'signature  (text  and/or  graphic(s))  as 
provided  by  expert  aided  diagnostic  application. 

C .  Note  no  search  to  prevent  duplicate  entries  for  same  anomaly. 

D.  Permit  user  to  edit  new  data  provided  by  expert  aided  diagnostic  application. 

E.  Permit  user  to  add  rid’no,  mr'no,  and  ucr'no. 

.2.1.3  Output 

Anomaly  datafile  with  added  anomaly  record.  Possibly  a  new  anomaly  signature. 
.2.2  Manual  Updates  of  Anomalies  Data 
.2.2.1  Input 

A.  Anomaly  data  file. 

B.  User  request  to  manually  update  dam 
.2.2.2  Process 

A.  User  enters  edit  mode. 

B .  Records  appear  from  Anomaly  data  files  indexed  by  test'no.  User  has 
keyboard  control  to 

Add  —  new  records 
Delete  -  a  character,  or  record 
Change  —  contents  of  any  field 
Save  —  work  to  date 
Abort  —  edits  this  session 
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1 

1 

c. 

Upon  exit  of  edit  mode,  edited  records  are  saved. 

1 

D. 

Reindex  edited  data  files. 

1 

4. 2. 3. 2. 2.3 

Output 

1 

Manually  edited  Anomaly  datafiles. 

4. 2. 3. 2. 3  Standard  Reports  of  Anomalies  Data 

1 

4. 2. 3. 2. 3.1 

Input 

1 

A. 

Anomaly  data  file. 

■ 

B. 

User  request  for  standard  report. 

1 

C. 

User  designation  of  report  sort  order  and  search  condition(s). 

4. 2. 3. 2. 3. 2 

Process 

1 

A. 

Open  Anomaly  data  file. 

1 

B. 

Construct  report  based  on  specified  sort  order  and  search  condition. 

1 

C. 

Display  results  on  screen  or  send  to  printer  as  requested. 

1 

4. 2. 3. 2. 3. 3 

Output 

Screen  display  or  printed  report 

1 

4. 2. 3. 3  Inspections/Data 

1 

4. 2. 3. 3.1  Manual  Updates  of  Inspection  Data 

■ 

4. 2. 3. 3. 1.1 

Input 

1 

A. 

Inspection  data  files. 

B. 

User  request  to  manually  update  data 

1 

4. 2. 3. 3. 1.2 

Process 

1 

A. 

User  enters  edit  mode. 

■ 

1 

1 

B. 

Records  appear  from  Inspection  data  files  indexed  by  test’no.  User  has 
keyboard  control  to 

Add  —  new  records 

Delete  —  a  character,  or  record 

Change  —  contents  of  any  field 

Save  —  work  to  date 

Abort  --  edits  this  session 

1 

C. 

Upon  exit  of  edit  mode,  edited  records  are  saved. 

1 
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D .  Reinde  x  edi  ted  data  files . 

4. 2. 3. 3. 1.3  Output 

Manually  edited  Inspection  datafiles. 

4 . 2 . 3 . 3 . 2  Standard  Repons  of  Inspection  Data 

4. 2. 3. 3. 2.1  Input 

A.  Inspection  data  files. 

B .  User  request  for  standard  report. 

C.  User  designation  of  report  sort  order  and  search  condition(s). 

4. 2. 3. 3. 2. 2  Process 

A.  Open  Inspection  data  files. 

B .  Construct  report  based  on  specified  son  order  and  search  condition. 

C.  Display  results  on  screen  or  send  to  printer  as  requested. 

4. 2. 3. 3. 2. 3  Output 

Screen  display  or  printed  report 
4. 2. 3. 4  Sigma  Data 

4. 2. 3. 4.1  Automated  Updates  of  Sigma  Data 

4. 2. 3. 4. 1.1  Input 

A.  Sigma  data  files. 

B .  Temporary  update  file  of  validated  SSME  hot  fire  data  as  analyzed  by 
special  application  module  sigma 

C .  User  permission  to  update  sigma  datafiles  with  data  from  this  test. 

4. 2. 3. 4. 1.2  Process 

A.  Open  sigma  data  files  and  temporary  update  file  produced  by  special 
application  sigma. 

B .  For  each  record  in  temporary  update  file. 

C.  Search  for  match  in  sigma'test  file  (key:  test’no  +  engine’phase  + 
power'level  +  pid'no) 

If  match 

THEN  display  record  exists  message.  Allow  user  to  overwrite. 
ELSE  update  sigma  data  files  with  info  from  new  test. 
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4. 2. 3. 4. 1.3  Output 


Automated  update  of  sigma  data  files. 

4. 2. 3. 4. 2  Manual  Updates  of  Sigma  Data 

4. 2. 3. 4. 2.1  Input 

A.  Sigma  data  files. 

B .  User  request  to  manually  update  data. 

4. 2. 3. 4. 2. 2  Process 

A.  User  enters  edit  mode. 

B .  Records  appear  from  Sigma  data  files  indexed  by  test’no.  User  has 
keyboard  control  to 

Add  --  new  records 
Delete  -  a  character,  or  record 
Change  --  contents  of  any  field 
Save  —  work  to  date 
Abort  -  edits  this  session 

C.  Upon  exit  of  edit  mode,  edited  records  are  saved. 

D .  Reindex  edited  data  files. 

4. 2. 3. 4. 2. 3  Output 

Manually  edited  Sigma  datafiles. 

4.2.3  4.3  Standard  Reports  of  Sigma  Data 

4. 2. 3. 4. 3.1  Input 

A.  Sigma  data  files. 

B .  User  request  for  standard  report. 

C.  User  designation  of  report  sort  order  and  search  condition(s). 

4. 2. 3. 4. 3. 2  Process 

A.  Open  Sigma  data  files. 

B .  Construct  report  based  on  specified  sort  order  and  search  condition. 

C .  Display  results  on  screen  or  send  to  printer  as  requested. 

4. 2. 3. 4. 3. 3  Output 

Screen  display  or  printed  report. 
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4 . 2 . 3 . 5  Specifications  Data 

4. 2. 3. 5. 1  Manual  Updates  of  Specifications  Data 

4. 2. 3. 5. 1.1  Input 

A.  Specification  data  files. 

B.  User  request  to  manually  update  data 

4. 2. 3. 5. 1.2  Process 

A.  User  enters  edit  mode. 

B .  Records  appear  from  Specification  data  files  indexed  by  test’no.  User  has 
keyboard  control  to 

Add  —  new  records 
Delete  —  a  character,  or  record 
Change  --  contents  of  any  field 
Save  —  work  to  date 
Abort  —  edits  this  session 

C .  Upon  exit  of  edit  mode,  edited  records  are  saved. 

D.  Reindex  edited  data  files. 

4. 2. 3. 5. 1.3  Output 

Manually  edited  Specification  datafiles. 

4. 2. 3. 5. 2  Standard  Repons  of  Specifications  Data 

4. 2. 3. 5. 2.1  Input 

A.  Specification  data  files. 

B .  User  request  for  standard  report. 

C.  User  designation  of  report  sort  order  and  search  condition(s). 

4. 2. 3. 5. 2. 2  Process 

A.  Open  Specification  data  files. 

B .  Construct  report  based  on  specified  sort  order  and  search  condition. 

C.  Display  results  on  screen  or  send  to  printer  as  requested. 

4. 2. 3. 5. 2. 3  Output 

Screen  display  or  printed  report. 
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4. 2. 3. 6  Test  Data 


4. 2. 3. 6.1  Automated  Updates  of  Test  Data 


4. 2. 3. 6. 1.1  Input 

A.  Full  SSME  CADS  or  Facility  Test  data  on  Perkin  Elmer-4. 

B .  Test  number,  start  and  end  times,  and  sampling  rate  provided  by  user. 

4. 2. 3. 6. 1.2  Process 


A.  Open  communications  link  to  VAX. 

B .  Lookup  test  number  on  VAX  to  see  if  a  copy  of  data  already  exists  for  the 
requested  test. 

C .  If  File  exists  on  VAX 

THEN  display  existing  header  record  information  to  user. 

Ask  user  if  they  want  new  data. 

IF  user  wants  new  data, 

THEN  proceed  to  next  step. 

ELSE  end  automated  update  without  new  data  transfer 

D.  Open  communications  link  to  PE-4. 

E.  Lookup  test  number  on  PE-4  on-line  disk  storage. 

F.  IF  file  exists  on  PE-4 

THEN  proceed  with  data  transfer  per  user  request 

ELSE  display  not  on  line  message  to  user.  Allow  tape  load  request 


4. 2. 3. 6. 1.3  Output 

SSME  Data  transferred  from  PE-4  to  VAX  at  user  requested  sampling  rate  and  start 
and  stop  times.  Data  storage  format  will  be  SSME  Data  Format  D  (see  Table  4-2). 


Rec# 

Sec# 

Record  Description 

Data  Type/Size 

1 

0 

File  Formatting  Information 

CMAR*252 

2 

1 

Comment  Record  1 

CHAR*252 

3 

2 

Comment  Record  2 

CHAR*252 

4 

3 

Comment  Record  3 

CHAR*252 

5 

4 

Comment  Record  4 

CHAR*252 

6 

5 

Comment  Record  5 

CHAR*252 

7 

6 

File  Map  (Time  words) 

REAL 

TW  (315) 

8 

1 1 

File  Map  (Disk  Records) 

INTEGER 

DR  (315) 

9 

16 

Zero  Shift  Data  Averages 

REAL 

ZS  (?) 

10 

* 

Staleness  Factors 

REAL 

SF  (?) 

1  1 

• 

Header  #1  (Test  Title) 

CHAR*? 

HI 

12 

• 

Header  #2  (Test  File  information) 

REAL 

H2  (63) 

13 

* 

Header  #3  (Measurement  IDs) 

CHAR*? 

H3  (?) 

1  4 

• 

Header  #4  (Engineering  units) 

CHAR*? 

H4(?) 

15 

Header  #5  (Measurement  Titles) 

CHAR*? 

H5(?) 

TABLE  4-2  SSME  Data  Format  D 
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Rec# 

Sec# 

Record  Description 

Data  Type/Stze 

16 

« 

\  Up  to  15  Optional  User  Defined 

\  Header  Records 

Data  may  be  of 

> 

any  type  and 

/  (number  of  records  specified 

/  in  header  record  2) 

size. 

? 

* 

Start  of  Test  Data 

\ 

1 

\ 

>  Test  Data  Records 

/ 

REAL  TD  (?) 

EOF 

/ 

End  of  Test  Data 

*  Sector  addresses  for  these  records  are  supplied  by  Header  record  number  2. 


GENERAL  RECORD  DESCRIPTIONS  FOR  FORMAT  D 

1 )  Record  #1  contains  information  about  the  format  of  the  file.  The  record  is  in  FORTRAN  type 
CHARACTER*252.  For  the  “D"  format  the  first  17  characters  of  this  record  are  as  lollows: 

"DATA  FORMAT=D  XXX" 

2)  XXX  is  a  three  digit  integer  number  which  holds  the  file  sector  number  of  header  record  2 
This  allows  programs  to  quickly  bypass  comment  and  filemap  records  if  so  desired  Character 
positions  18  through  252  may  be  used  as  desired.  Normally,  the  name  of  the  file  generating 
program  and  it's  version  number  are  specified  enclosed  in  asterisks  (*).  For  example,  if  a  program 
called  “SCALETTB"  were  to  produce  a  format  “D”  file,  the  first  record  might  read: 

“DATA  FORMATED  1 1 6  ‘SCALETTB  vl  .31  *" 

3)  The  program  name  including  the  asterisks  should  not  be  over  20  characters  long  because 
utility  routines  exist  which  make  this  field  available  to  user  programs  as  a  CHARACTER*20  entity 
The  program  name  field  may  appear  anywhere  in  the  record  except  in  the  first  17  characters 

4)  Records  #2  through  #6  is  free  file  space  not  currently  used.  Any  file  creation  program  may 
use  this  area  to  hold  comments,  program  specific  data.  ect.  Each  record  is  of  type 
CHARACTER*252. 

5)  Records  #7  and  #8  contain  a  map  of  the  file's  data  area.  Record  #7  is  315  REAL  words  and 
record  #8  is  315  INTEGER  words.  The  file  generating  program  does  not  compute  the  data  for 
these  two  records;  instead,  programs  write  two  dummy  records  as  place  holders.  After  the 
complete  file  is  written,  a  program  utility  “FILMAP"  is  used  to  scan  the  test  data  portion  of  the  file 
and  overwrite  the  two  dummy  records  with  file  mapping  information.  The  methods  used  to  map  a 
file  are  detailed  in  document  "SSME  SINGLE  ENGINE  TEST  DATA  ACCESS”  number  IL  86-129- 
289  in  section  3.7  “DAT ACC. LIB  File  Mapping  Method".  Programs  which  later  read  data  may  use 
routines  designed  to  use  the  file  map  to  directly  access  any  record  in  the  file's  test  data  area. 

6)  Record  #9  contains  zero  shift  averages  as  REAL  words.  The  zero  shift  averages  are 
produced  by  averaging  the  test  data  over  the  -2  to  -1  second  time  period  before  engine  start.  The 
resulting  averages  may  then  be  used  by  user  programs  to  compute  a  bias  to  apply  to  certain  test 
parameters  in  order  to  correct  calibration.  File  generating  programs  do  not  not  need  to  compute 
the  data  for  this  record;  instead,  programs  write  one  dummy  record  of  zero  values  (0.0)  as  a  place 
holder.  After  the  complete  file  is  written,  a  program  utility  “FILEMAP”  is  used  to  compute  the  zero 
shift  values  and  overwrites  this  record.  If  the  zero  shift  values  can  not  be  computed,  the  zero 
values  are  left  in  place  causing  programs  which  use  zero  shifts  to  apply  no  bias. 


TABLE  4-2  SSME  Data  Format  D  (Cont'd) 
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7)  Record  #10  contains  staleness  factors  for  each  measurement  listed  ;  i  rec.-r  713  The 
staleness  factor  is  the  time  adjustment  to  be  added  to  time  to  compute  the  exact  time  at  which 
each  individual  measurement  value  was  recorded.  Any  file  creation  program  should  compute 
these  factors  and  insert  this  record.  If  the  staleness  factors  are  not  known  or  not  computable,  a 
record  of  zero  values  (0.0)  should  be  written.  This  will  cause  user  programs  which  apply  stateness 
to  ignore  any  time  adjustment. 

8)  Record  #1 1  contains  the  first  of  five  standard  header  records.  Header  #1  constitutes  the  test 
title  in  FORTRAN  type  CHARACTER  and  may  be  of  any  length.  Word  number  22  in  header  #2 
points  to  the  sector  of  header  #1  and  word  23  indicates  it's  length.  A  common  CADS  file  might 
have  "SSME  CONTROLLER  DATA  FOR  TEST  9010460"  written  in  this  record. 

9)  Record  #12  contains  header  #2.  In  this  record  there  are  63  floating  point  words  which  give 
information  about  the  test  file  itself.  These  63  words  are  described  by  the  following: 

WORD  DESCRIPTION 

1  Spare  (normally  0.0) 

2  Spare  (normally  0.0) 

3  Number  of  PIDS  contained  in  this  file 

4  Spare  (normally  0.0) 

5  Spare  (normally  0.0) 

6  Number  of  PIDS  plus  one  plus  time  word 

7  Spare  (normally  1 .0) 

8  'Test  Stand  Number  (901 =A1, 902=A2,  750=A3,  904=BI) 

9  'Test  Run  Number 

1  0  Year  and  Day  (ie  5070.  for  85:070) 

1  1  Spare  (normally  0.0) 

1  2  Spare  (normally  0.0) 

1  3  Engine  Cutoff  Time  in  Seconds 

1 4  Sector  Address  of  the  Start  of  Test  Data  Area 

1 5-20  Calender  Time  of  Engine  Start  in  the  form  Years, Days,  Hours,  Mins,  Secs,  Msecs 

21  Engine  Serial  Number 

22  Sector  Address  of  Header  #1 

23  Character  Length  of  Header  #1 

24  Sector  Address  of  Header  #2 

25  Sector  Address  of  Header  #3 

2 6  Character  Length  of  Header  #3 

2  7  Sector  Address  of  Header  #4 

28  Character  Length  of  Header  #4 

29  Sector  Address  of  Header  #5 

30  Character  Length  of  Header  #5 

3 1  Sector  Address  of  Zero  Shift  Averages 

32  Sector  Address  of  Staleness  Factors 

33  Number  of  User  Defined  Header  Records  (0-15) 

34  Sector  Address  of  1st  User  Header  Record 

35  Entity  Length  of  1st  User  Header  Record 


62  Sector  Address  of  15th  User  Header  Record 

63  Entity  Length  of  15th  User  Header  Record 


TABLE  4-2  SSME  Data  Format  D  (Cont'd) 
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When  this  file  format  is  used  to  contain  STS  flight  data,  a  “single-engine-like"  test  run  number 
must  be  synthesized  for  words  8  and  9.  The  method  used  is  as  follows: 

Word  8,  Characters  1  -3  =  STS  Mission  Number  or  MPTA  Test  Number 
Word  9,  Character  1  =  Cycle  Number  for  MPTA  or  STS  Scrub/ Abort 
Word  9,  Character  2  =  Event  Site  (0-KSC,  1-VAB,  2-NSTL) 

Word  9,  Character  3  =  Event  Type  (0-STS,  1-Scrub,  2-Abort,  3-FRF,  4-MPTA) 

Word  9,  Character  4  =  Engine  Position  (1 -ME1 ,  2-ME2,  3-ME3) 


10)  Record  #13  contains  header  #3.  This  record  is  a  list  of  the  measurement  IDs  available  in  the 
file  Each  ID  is  of  type  CHARACTER  and  may  of  any  length.  Header  #2,  words  25  and  26,  specify 
the  sector  address  and  string  length  of  header  #3  entities.  The  order  in  which  the  measurements 
are  listed  identifies  the  order  in  which  all  other  header  and  data  records  are  written  The  PID 
number  is  usually  in  the  first  four  characters. 

1 1 )  Record  #14  contains  header  #4.  This  record  supplies  the  engineering  unit  of  measure  for 
each  item  in  header  #3.  Each  unit  is  of  type  CHARACTER  and  may  be  of  any  length.  Header  #2, 
words  27  and  28,  specify  the  sector  address  and  string  length  of  header  #4  entities. 

12)  Record  #15  contains  header  #5.  This  record  supplies  the  title  of  each  item  in  header  #3 
Each  title  is  of  type  CHARACTER  and  may  be  of  any  length.  Header  #2,  words  29  and  30.  specify 
the  sector  address  and  string  length  of  header  #5  entities. 

13)  The  next  ID  records  may  be  used  by  users  to  add  special  header  records  to  the  file  The 
type  and  length  of  the  entities  are  up  to  the  user  to  define.  Since  these  records  are  optional,  no 
user  defined  records  may  be  defined  for  some  files.  Word  33  of  header  #2  specifies  the  number 
of  records  defined. 

14)  All  remaining  records  in  the  file  are  test  data  records.  Each  data  record  constitutes  a  floating 
point  data  sample  in  time  for  all  PIDs  listed  in  header  #3.  Word  14  of  header  #2  specifies  the 
sector  address  of  the  first  data  record. 


TABLE  4-2  SSME  Data  Format  D  (Cont'd) 

4. 2. 3. 6. 2  Manual  Updates  of  Test  Data 

4. 2. 3. 6. 2.1  Input 

A.  Test  Data  data  files. 

B.  User  request  to  manually  update  data 

4. 2. 3. 6. 2. 2  Process 

A.  User  enters  edit  mode. 


B .  Records  appear  from  Test  Data  data  files  indexed  by  test  no.  User  has 
keyboard  control  to 

Add  -  new  records 

Delete  -  a  character,  or  record 

Change  --  contents  of  any  field 

Save  -  work  to  date 

Abort  -  edits  this  session 


C.  Upon  exit  of  edit  mode,  edited  records  are  saved. 


D. 


Reindex  edited  data  files. 


4. 2. 3. 6. 2. 3  Output 

Manually  edited  Test  Data  datafiles. 

4. 2. 3. 6. 3  Standard  Reports  of  Test  Data 

4. 2. 3. 6. 3.1  Input 

A.  Test  Data  data  files. 

B .  User  request  for  standard  report. 

C.  User  designation  of  report  sort  order  and  search  condition(s). 

4. 2. 3. 6. 3. 2  Process 

A .  Open  Test  Data  data  files. 

B .  Construct  report  based  on  specified  sort  order  and  search  condition. 

C .  Display  results  on  screen  or  send  to  printer  as  requested. 

4. 2. 3. 6. 3. 3  Output 

Screen  display  or  printed  report. 


4 . 3  COMPUTER  AIDED  ENGINEERING 

4.3.1  Appiicano.ns.BGQgaiu^ 

Two  applications  are  required  to  provide  the  necessary  computer  aided  engineering 
(CAE)  capability  to  the  workstation  (see  Figure  4-5).  An  interface  application  will  retrieve 
and  format  data  from  the  integrated  databases  and  a  commercial  CAE  package  will  provide 
the  graphical  data  analysis  functions  for  the  CAE  environment. 

The  data  interface  application  provides  access  to  SSME  test  and  flight  data  as  a  user 
defined  set  of  parameter  retrievals  from  the  Ingres  database.  The  interface  application  will 
fomiat  the  data  for  the  analysis  program  as  required. 

A  commercial  CAE  application  will  be  selected  to  provide  the  CAE  environment. 
Data  will  be  supplied  to  the  program  from  the  integrated  database  by  the  data  interface 
application.  Batch  programs  will  generate  pre-defined  plots  for  each  test  segment.  Output 
will  be  available  on  screen  in  real  time,  or  as  post-script  output  suitable  for  a  laser  printer. 
The  user  will  be  able  to  actively  manipulate,  analyze,  and  redisplay  the  test  data  sets  using 
features  of  the  commercial  package. 

The  analysis  process  for  each  SSME  test  or  flight  will  begin  when  the  parametric 
data  has  been  transferred  to  the  file  server.  Plot  data  set  definitions  and  report  formats 
developed  by  individual  analysts  will  be  input  to  this  process. 


PE4  Integrated  Database 


FIGURE  4-5  CAE  Functionality  Will  Be  Provided  by  a  Commercial  CAE 
Program  in  Concert  with  an  Automated  Interface  to  the 
Integrated  Database 
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The  CAE  application  will  be  menu  driven.  The  analyst  can  select  pre-defined  plot 
packages  for  on  line  examination  or  hard  copy  print.  Data  will  include  test  parameters,  pre¬ 
defined  text,  a  textual  data,  curve  fits,  statistics,  etc.  defined  for  the  plot  format.  The 
analyst  can  flexibly  manipulate  the  plot  display  using  the  mouse  to  zoom  and  enhance 
scaling  accuracy,  identify  numeric  values  of  specific  plotted  points  under  mouse  control, 
and  edit  data  including  cut/paste  functions.  Multiple  windows  can  be  opened 
simultaneously  to  compare  data  on  different  plots. 

Plot  information  may  be  printed  at  any  time  to  the  laser  printers.  Additionally,  a  full 
set  of  "canned"  plots  can  be  created  in  hard  copy  using  a  batch  operation. 

Output  formats  will  include  a  wide  variety  of  2D/3D  formats  for  data  display.  Plot 
definitions  will  allow  layouts  to  be  pre-defined  with  plots  produced  when  the  program  is 
executed.  Plots  which  have  been  created  can  be  stored  and  accessed  for  later  comparison 
as  examples  of  nominal  or  anomalous  behavior. 

4.3.2  Evaluation  of  CAE  packages 

Over  forty  commercial  data  analysis,  graphics,  and  statistics  packages  were 
evaluated  (see  Figure  4-6)  to  determine  their  potential  suitability  for  this  application.  The 
following  required  feature  provided  the  basis  for  evaluation: 

a.  Compatible  with  a  SUN  workstation  including  multi-window 
operation; 

b.  Flexible  data  input  formats  including,  if  possible,  easily 
implemented  bridges  to  the  Ingres  databases  and  sufficiently  large 
data  table  size; 

c.  Flexible  2D/3D  full  color  graphics  including  a  wide  variety  of  plot 
formats; 

d .  Post-script  output  device  support; 

e .  Batch  and  macro  operation  available  to  provide  standard  sets  of  plot 
repons  for  each  test  segment; 

f.  Application  language  for  implementation  of  mathematical 
manipulation,  statistics,  and  signal  processing  functions; 

g.  Fully  integrated  mouse  support  including  autozoom,  data  cut,  paste 
and  editing  and  data  value  examination  under  mouse  control; 

h.  Data  management  capabilities  within  the  analysis  program  itself  to 
allow  storage  and  retrieval  of  plot  images  without  regeneration  of  the 
parametric  data;  and 

i.  Efficient  operation  and  suitable  response  time  on  selected  processor 
platform. 


54 


55 


FIGURE  4-6  Summary  of  Commercial  Packages  Investigated 


FIGURE  4-6  Summary  of  Commercial  Packages  Investigated  (Cont’d) 
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FIGURE  4-6  Summary  of  Commercial  Packages  Investigated  (Cont’d) 


TYPE  DATA  A  ITU  input 

PROCRAM  MANAGE  CATION  FILK  APPROX 

CAN  NAME  VENDOR  PLOT  MATH  STAT  OTHER  -MENT  LANGUAGE  FORMAT  PRICE _ COMMENTS 


FIGURE  4-6  Summary  of  Commercial  Packages  Investigated  (Cont’d) 
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FIGURE  4-6  Summary  of  Commercial  Packages  Investigated  (Cont'd) 


Several  commercial  CAE  packages  appear  to  satisfy  these  requirements.  These 


packages 

(and  vendors)  are  as  follows: 

a. 

TECPLOT  (Amtec,  Inc.); 

b. 

RS/1  (BBN  Software.  Inc.); 

c. 

MATLAB  (Mathworks,  Inc.); 

d. 

TempleGraph  (Mihalisin  Assoc.); 

e. 

TECHBASE  (MINEsoft  Ltd.); 

f. 

PV~Wave  (Precision  Visuals,  Inc.); 

g- 

SAS/Graph  (SAS  Institute,  Inc.);  and 

h. 

Unigraph  2000  (Uniras  Inc.). 

More  detailed  evaluation  and  benchmarking  of  these  candidates  are  recommended. 


4 . 4  SPECIAL  APPLICATIONS 

4.4.1  Application  List  and  Output 

The  special  applications  module  consists  of  diagnostic  and  data  evaluation 
applications  that  are  primarily  procedural  in  nature.  These  applications  are  used  to  filter  test 
data  and  identify  directly  measured  operating  anomalies  and  definitive  violations  of 
operating  specifications.  As  such,  they  provide  a  first  cut  at  the  feature  identification 
abilities  required  in  the  more  sophisticated,  heuristic  data  evaluations  to  be  accomplished  in 
the  expert-aided  diagnostics  module. 

Many  of  these  special  applications  are  a  pan  of  the  current  diagnostic  procedures. 
Some  of  these  applications,  such  as  for  evaluation  of  green  run  data,  have  even  been 
developed  into  FORTRAN  programs  on  the  Perkin  Elmer  and  are  currently  in  use  as 
individual  tools  to  aid  in  the  diagnostic  process.  These  programs  will  be  ported  to  the  Sun 
workstation  and  will  be  integrated  into  this  diagnostic  system.  Thus,  the  current  diagnostic 
procedures  will  be  incrementally  enhanced  by  building  upon  systems  and  procedures 
already  in  place. 

The  special  applications  which  have  been  identified  as  are: 

a.  Sensor  Data  Validation  and  Signal  Reconstruction; 

b.  Startup  Analysis; 

c.  Shutdown  Analysis; 

d.  Main  Stage  Analysis; 

e.  Green  Run  Analysis;  and 

f .  Steady  State  Power  Balance. 

The  user  will  start  each  of  these  applications  through  a  menu-driven  selection 
program  on  the  Sun  workstation.  Each  of  these  applications  will  operate  on  data  stored  in 
the  integrated  database. 

4.4.2  Special  Applications  HTPO  Analysis 

Details  of  the  input  data  requirements,  the  process  logic  and  output  from  each  of  the 
special  applications  will  now  be  presented  in  the  form  of  HIPO  charts. 
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This  application  will  detect  and  isolate  hard  and  soft  sensor  failures  in  the  hot  fire 
data,  calibration  and  scaling  errors  will  also  be  detected  on  certain  critical  parameters.  When 
one  of  these  sensor  failure  is  identified,  an  estimate  of  the  correct  sensor  value  will  be 
generated  and  the  hot  fire  data  set  will  be  updated. 

4.4.2. 1.1  Input 

A .  User  request  to  validate  data. 

B .  User  supplied  test  number  to  validate. 

C.  User  supplied  previous  tests  for  comparison. 

D.  CADS  data  for  the  selected  tests. 

4.4.2. 1.2  Process 

The  process  of  the  sensor  validation  task  is  currently  being  developed  under  the 
Sensor  Data  Validation  Task  of  the  Life  Prediction  Program. 

4.4.2. 1.3  Output 

A.  Validated  and  Reconstructed  PID’s. 

B .  Identification  of  reconstructed  PID  numbers. 

4. 4. 2. 2  Startup  Analysis 

This  application  will  calculate  critical  characteristics  of  the  startup  transient  (from 
engine  start  to  engine  start  plus  6  sec)  of  the  engine.  Comparison  of  the  engine  start  will  be 
made  against  the  start  confirm  criteria  and  the  two  sigma  startup  database. 

4. 4. 2. 2.1  Input 

A.  User  request  to  perform  analysis  of  startup  transient. 

B .  User  specified  test  number. 

C.  CADS  and  Facility  data  for  the  test. 

D.  Start  confirmation  criteria. 

E.  Two  sigma  startup  data. 

4.4.2. 2.2  Process 

A.  Open  CADS  and  Facility  data  files  for  selected  test. 

B .  Open  two  sigma  startup  data  file. 

C .  Calculate  prime  times  for 

( 1 )  Fuel  pre-bumer, 

(2)  ox  pre- burner,  and 
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(3)  Main  combustion  chamber. 

D.  Evaluate  turbine  discharge  temperature  measurements  against  start  conf  irm 
criteria. 

E.  Examine  data  for  existence  of  fuel  side  oscillations. 

F.  Compare  sensor  data  with  two  sigma  startup  values.  Report  the  number  of 
two  sigma  excursions,  the  length  of  time  above  or  below  two  sigma,  and 
the  minimum  and  maximum  excursion  from  two  sigma  for  each  data 
channel  evaluated. 

G.  Generate  temporary  file  of  average  values  from  this  test  for  automated 
update  of  sigma  values. 

H .  Generate  startup  evaluation  sheet. 

4. 4. 2. 2. 3  Output 

A.  Startup  evaluation  sheet. 

4.4.2. 3  Shutdown  Analysis 

This  application  will  calculate  the  shutdown  characteristics  of  the  engine.  Evaluation 
of  the  thrust  decay  rate,  purge  and  valve  sequencing  will  be  made  against  specification 
requirements.  There  is  currently  no  two  sigma  database  for  shutdown  values  and 
development  of  one  was  not  characterized  as  a  high  priority  by  the  diagnostic  experts. 

4. 4. 2. 3.1  Input 

A.  User  request  to  perform  analysis  of  shutdown  transient. 

B .  User  specified  test  number. 

C.  CADS  and  Facility  data  for  the  test. 

D.  Shutdown  specification  criteria. 

4. 4. 2. 3. 2  Process 

A.  Open  CADS  and  Facility  data  files  for  selected  test. 

B .  Calculate  thrust  decay  rate.  Compare  with  specification  requirement. 

C.  Calculate  timing  of  the  valve  and  purge  shutdown  sequence.  Compare  with 
specification  requirements. 

4.4.2. 3. 3  Output 

A.  Shutdown  analysis  sheet. 

4 . 4 . 2 . 4  Mainstage  Analysis 

This  application  will  compare  steady  state  operation  of  the  engine  at  all  standard 
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power  levels  with  the  two  sigma  data  bases.  Performance  comparisons  will  be  generated 
for  all  measurements  at  standard  power  levels. 

4. 4. 2. 4.1  Input 

A.  User  request  to  perform  mainstage  two  sigma  analysis. 

B .  User  specified  test  number. 

C .  CADS  and  Facility  data  for  the  test. 

D.  Sigma  database. 

4. 4. 2. 4. 2  Process 

A.  Open  CADS  and  Facility  files  and  sigma  database  file 

B .  Locate  the  point  in  the  test  of: 

( 1 )  Maximum  fuel  turbine  discharge  temperature  at  65%  RPL; 

(2)  Maximum  fuel  turbine  discharge  temperature  at  100%  RPL; 

(3)  Maximum  fuel  turbine  discharge  temperature  at  104%  RPL; 
and 

(4)  Maximum  fuel  turbine  discharge  temperature  at  109%  RPL. 

C .  For  each  of  these  test  times,  calculate: 

( 1 )  HPOTP  Inlet  Pressure,  psia; 

(2)  HPOTP  Discharge  Pressure,  psia; 

(3)  PBP  Discharge  Pressure,  psia; 

(4)  LPTOP  Speed,  rpm; 

(5)  HPOT  Discharge  Temp  (Ch  A),  R; 

(6)  HPOT  Discharge  Temp  (Ch  B),  R; 

(7)  HPOP  Speed,  RPM; 

(8)  HPFTP  Inlet  Pressure,  psia; 

(9)  HPFTP  Discharge  Pressure,  psia; 

(10)  HPFP  Discharge  Temp,  R; 

(11)  LPFTP  Speed,  RPM; 

(12)  HPFTP  Speed,  RPM; 

(13)  HPFT  Discharge  Temp  (Ch  A),  R; 

(14)  HPFT  Discharge  Temp  (Ch  B),  R; 

(15)  OPOV  Position; 

(16)  OPB  Pc,  psia; 

(17)  FPO V  Position ; 

( 1 8)  MCC  coolant  Discharge  Temp,  R;  and 

(19)  MCC  coolant  Discharge  Pressure,  psia. 

D.  Compare  these  test  values  with  the  mean  and  sigma  values  stored  in  the 
sigma  database. 

E.  Generate  the  performance  comparison  report  at  each  power  level. 

F .  Record  the  average  values  calculated  for  each  power  level  in  a  temporary  file 
for  eventual  update  to  the  sigma  database  (to  incorporated  into  sigma 
database  upon  user  request). 
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4. 4. 2. 4. 3  Output 


A.  Performance  comparison  report  (see  Figure  4-7). 

B .  Update  File  for  sigma  database. 

4.4.2  5  Green  Run  Analysis 

This  application  evaluates  the  test  profile  and  engine  performance  against  green  run 
specifications  and  produces  preliminary  green  run  summary  sheets.  This  preliminary  green 
run  summary  sheet  is  used  to  determine  if  the  tested  component(s)  met  all  green  run 
requirements. 

4. 4. 2. 5.1  Input 

A.  User  request  to  perform  green  run  analysis. 

B .  User  specified  test  number. 

C.  Component(s)  being  evaluated. 

D.  CADS  and  Facility  data  for  the  test. 

E.  Green  run  specification  criteria. 

4. 4. 2. 9. 2  Process 

A.  Open  CADS  and  Facility  files  and  green  nin  specification  file. 

B .  calculate  accumulated  time  at  each  power  level  based  on  PC. 

C.  Compare  with  green  run  specifications  for  minimum  operating  time. 

D.  Calculate  the  point  in  test  of; 

(1)  Minimum  NPSP  on  LAX  side  at  104%  AFL; 

(2)  Maximum  NPSP  on  LAX  side  at  104%  RPL; 

(3)  Minimum  NP6P  on  LAX  side  at  109%  RPL; 

(4)  Maximum  NPSP  on  LAX  side  at  109%  RPL; 

(5)  Minimum  NPSP  on  Final  side  at  104%  RPL;  and 

(6)  Minimum  NP6P  on  Fuel  side  at  109%  RPL. 

E.  For  each  of  these  six  points  in  the  test,  determine  if  NPSP  specifications  are 
met. 

F.  For  each  of  the  acceptable  NPSP  points,  calculate; 

(1)  FLPFT  discharge  temperatures; 

(2)  Coolant  liner  delta  P; 

(3)  Coolant  liner  tern  mature; 

(4)  Primary  ox  seal  drain  pressure; 

(5)  In'.ermediate  seal  purge  pressure; 

(6)  Secondary  seal  cavity  pressure; 

(7)  Turbine  discharge  primary  seal  pressure; 

(X  Turbine  discharge  temperature; 
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(9)  HPOTP  speed;  and 

(10)  HPOTP  PBP  Discharge  pressure. 


G .  Prepare  specification  test  results  for  the  appropriate  component(s). 

4. 4. 2. 5. 3  Output 

Preliminary  green  run  summary  sheets  (Figure  4-8  and  4-9). 

4. 4. 2. 6  Steady  State  Power  Balance 

The  steady  state  power  balance  is  used  to  perform  mass  balances  and  calculate 
temperatures,  pressures  and  flowrates  where  direct  measurements  are  not  available.  From 
these  operating  conditions,  turbine  and  pump  efficiencies  and  performance  ratios  are 
calculated  which  can  be  used  to  predict  the  performance  of  the  engine  at  alternate  operating 
points  and  standard,  rated  conditions. 

The  steady  state  power  balance  is  a  FORTRAN  application  which  is  run  on  the 
IBM-3084  at  MSFC.  This  application  could  be  ported  to  the  Sun  workstation  and  run 
locally  or  access  to  the  IBM-3084  could  be  provided  using  the  Sun  as  a  terminal. 

4. 4. 2. 6.1  Input 

A.  CADS  and  Facility  data  which  has  been  reduced  to  one  second  average 
files. 

B .  JCL  to  initiate  program  execution. 

4. 4. 2. 6. 2  Process 

Refer  to  the  SSME  Model  Documentation  assembled  by  the  Martin  Marietta  Model 

Group. 

4. 4. 2. 6. 3  Output 

A.  Predicted  C2  and  Kf  constants  and  rated  performance  of  the  engine  at 
standard  conditions  (see  Figure  4-10). 


4 . 5  EXPERT  AIDED  DIAGNOSTICS 

4.5.1  Applications  List 

4 . 5 . 1 . 1  Features  Identification 

This  application  examines  transient  parameter  readings  to  determine  if  specific 
features  exist  in  the  data.  Features  include  level  exceedances,  step  shifts,  oscillations, 
decays,  etc.,  which  define  potentially  anomalous  engine  behavior.  Certainty  values  will  be 
estimated  for  each  potential  anomaly  identified. 
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GREEN  RUN  CRITERIA 
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FIGURE  4-8  Green  Run  Evaluation  Report  for  HPFTP 
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FIGURE  4-9  Green  Run  Evaluation  Report  for  HPOTP 
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FIGURE  4-10  Steady  State  Performance  Model  Report 


4.5. 1 .2  Featurcs-to- Anomalies  Generator 

This  application  is  a  user-friendly  input  program  to  allow  analysts  to  capture  the 
reasoning  used  to  isolate  specific  anomalies  from  SSME  test  data.  This  application  will  be 
written  using  the  NEXPERT  Object  shell.  Steps  include  specification  of  critical  features  in 
certain  data  channels,  associated  history  or  configuration  information,  and  methods  for 
differentiating  competing  diagnoses. 

4 . 5 . 1 . 3  Expert  Aided  Diagnosis 

This  application  will  assist  the  data  analyst  in  sequentially  examining  test  results 
presented  using  predefined  plot  formats.  The  application  will  be  written  using  the 
NEXPERT  Object  shell.  The  application  will  accept  the  expen  user's  judgements 
concerning  the  existence  and  severity  of  anomalous  data  features  and  uses  its  inference 
mechanism  to  suggest  failure  mechanisms. 

4 . 5 . 1 . 4  Advanced  Diagnostics 

Other  approaches  to  expert  aided  diagnostics  will  he  hosted  by  the  system. 
Modules  to  support  other  programs  such  as  "deep"  reasoning  about  physical  causality  can 
be  integrated  directly  into  the  workstation  structure. 

4.5.2  Expert  Aided  Diagnostics  H1PO  Analysis 

4.5.2. 1  Feature  Generator 

4. 5. 2. 1.1  Input 

A.  CAD  and  facility  sensor  channel  data  from  the  current  test  or  flight. 

B.  Feature  database  entry  for  sensor  anomalies  including  the  following 
elements  (see  Figure  4-11  for  typical  entry  screen  layout): 

( 1 )  Sensor  channel  identifier, 

(2)  Operating  mode; 

(3)  Feature  descriptions;  and 

(4)  Threshold  or  reference  values. 

4. 5. 2. 1.2  Process 

This  application  (see  Figure  4-12)  will  automatically  analyze  test  data  channels  to 
detect  anomalous  features: 

a.  Open  feature  descriptor  table  defining  data  channels  and  test  phases 
for  examination; 

b.  For  each  test  phase  (start,  mainstage,  and  cutoff),  access  data  for 
channels  defined  in  feature  table; 

c.  For  each  data  channel  data  set  and  feature  type,  (e.g.  threshold 
exceedance,  2-sigma  bounds  checks  or  oscillation)  call  automatic 
analysis  module  to  perform  feature  detection; 
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NAME 


M  C  C_L  N_C  A  V_P  R 


PARAMETERS:  MCC  LN  CAV  PR  1  (1951) 
MCC  LN  CAV  PR  2  (1952) 
MCC  LN  CAV  PR  3  (1953) 


FEATURE 

PHASE 

Iffl 

RELATION 

REFERENCE 

OT 

START 

UNDERSHOOT  OVER  2o  THRESHOLD 

ABOVE 

2a 

UT 

START 

BELOW  2o  BAND 

BELOW 

2a 

DIV 

START 

SENSOR  A/B/C  DIVERGENCE 

DIVERGE 

0.5  PSI 

OM 

ALL 

LEVEL  ABOVE  MAXIMUM 

ABOVE 

0.5  PSI 

FIGURE  4-11  Typical  Entry  Screen  Layout  for  Feature  Description  Table 


SSME 

Test 

Data 


Feature 

Descriptor 

Table 


FIGURE  4-1 2  The  Feature  Generator  Detects  Pre-Defined 

Characteristics  in  Test  Data  and  Makes 
Entries  in  Feature  List 


74 


RLE 

TEST 

DATE 

PHASE 

PARAMETER 

FEATURE 

RULES 

SI 

A2-492 

2/13/90 

START 

MCC  LN  CAV  PR  1 

UNDERSHOOT  ABOVE  2o  THRESHOLD 

VES  I 

S2 

A2-492 

2/13/90 

START 

MCC  LN  CAV  PR  3 

UNDERSHOOT  ABOVE  THRESHOLD 

YES 

m 

A2-492 

2/13/90 

MAINST  AGE 

HPOT  DS  TMP 

CHANNEL  A/B  DIVERGENCE 

NO 

M  1 

A2-492 

2/13/90 

(1AINST  AGE 

HPFP  IN  TEMP 

OVERSHOOT  ABOVE  THRESHOLD 

YES 

M  1 

A2-492 

2/13/90 

MAINST  AGE 

PBP  DS  TMP 

INCREASING  DURING  SS  OPS 

YES 

FIGURE  4-13  Test  Anomalies  Index  Presents  Anomaly  Features  Detected 
In  the  Test  Data  and  Acts  as  a  Menu  Index  for  Subsequent 
Data  Analysis  (Typical  Format) 
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d.  Analysis  modules  will  return  indication  of  the  existence  of  features 
and  a  confidence  level  (e.g.  measures  relating  to  amount  of 
exceedance,  time  over  limit,  and  other  severity  indicators);  and 

e.  For  features  detected,  enter  feature  symbol  (created  from  feature 
name,  parameter,  and  feature  descriptor  e.g. 
MCC_LN_CAV_PR_l_OT)  and  confidence  into  feature  list  for  test 
and  segment.  For  features  defined  with  "negative  reporting",  enter 
feature  name  with  confidence  level  of  feature  not  existing. 

Features  detected  in  the  data  will  be  combined  in  the  Feature  List  with  other 
diagnostic  facts  derived  in  the  special  diagnostic  applications  (see  Section  4.4).  The 
Feature  List  acts  as  a  blackboard  for  expert  aided  diagnosis  and  advanced  diagnostic 
applications.  This  blackboard  file  is  maintained  as  part  of  the  NEXPERT  Object  file 
system  and  exists  outside  of  the  integrated  database.  The  blackboard  file  is  the  interface 
between  the  information  in  the  integrated  database  and  the  diagnostic  processes 
implemented  in  the  NEXPET  Object  shell. 

4.5.2. 1.3  Output 

A.  Diagnostic  facts  derived  from  the  features  and  written  to  the  blackboard  file 
for  each  match  or  partial  match  of  an  anomalous  feature  in  a  test  data 
channel. 

B .  Confidence  level  in  each  fact  based  on  the  number  and  degree  of  feature 
matches  between  data  and  reference  descriptors. 

4. 5. 2. 2  Features -to- Anomalies  Generator 


This  application  will  generate/update  the  rulebase  of  the  expen  aided  diagnostics 
maintained  by  NEXPERT  Object  using  tools  which  are  part  of  the  shell.  The  rules  describe 
the  relationships  between  observed  data  (i.e.  test  data,  inspection  reports,  prior  test, 
component  history,  and  component  age)  and  observed  hardware  failures.  The  program 
will  capture  the  experience  of  the  data  analyst  who  discovers  and  diagnoses  a  new  type  of 
failure  or  it  will  update  the  reasoning  path  based  upon  experience  with  a  recognized  failure 
event.  The  program  will  be  the  vehicle  for  knowledge  maintenance  and  will  permit  the 
users  of  the  system  to  develop  and  enhance  the  diagnostic  effectiveness  of  expert  aided 
diagnosis  through  use  of  the  workstation  for  data  analysis: 


4. 5.2. 2.1 

A. 

B. 

4. 5. 2. 2. 2 

A. 

B. 

C. 


Input 

Current  knowledge  (i.e.  captured  rules)  relating  the  occurrence  of 
anomalous  data  features  to  associated  hardware  or  test  failures. 

Expen  experience  and  judgement  of  the  data  analyst  user. 

Process 

Open  knowledge  base  (maintained  in  NEXPERT  Object). 

Select  existing  or  new  rule  set  ("knowledge  island")  used  to  process  a  given 
anomalous  feature. 

Obtain  decision  network  diagram  of  rule  set  to  assist  in  visualization  of  rule 
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relationships  (using  NEXPERT  Object  feature). 

D.  Update  rule  base  structure  relating  observed  data  anomalies  with  causative 
hardware  failures  based  upon  new  knowledge  about  the  meaning  of 
observed  features. 

E.  Define  new  data  features  or  facts  if  required. 

F .  For  each  rule,  define  user  prompt  for  fact  and  a  pre-defined  plot  or  report 
format  to  be  produced  when  the  data  display  function  is  selected  (at  each 
step,  a  hot  key  will  permit  the  user  to  have  access  to  the  test  data  beginning 
with  a  pre-defined  plot  format  for  the  particular  node  (see  Figure  4-14). 

G .  On  completion  of  user  changes,  update  the  knowledge  base  file  (maintained 
by  NEXPERT  Object). 

4. 5. 2. 2. 3  Output 

An  updated  knowledge  base  (rule  base)  describing  the  relationships  between 
observed  anomalies,  historical  data,  maintenance  and  inspection  reports  time/life 
considerations  and  hardware  failures. 

4 . 5 . 2 . 3  Expen  Aided  Diagnostics 

The  expert  aided  diagnosis  application  (resident  in  the  NEXPERT  Object  shell)  uses 
the  knowledge  base  and  features  discovered  in  the  test  data  to  control  investigation  of 
anomalies  and  inference  concerning  the  cause  (if  any)  of  the  problem. 

This  program  uses  a  "flat"  knowledge  representation  ”'hich  is  based  upon  heuristic 
rules  rather  than  reasoning  on  the  physical  phenomena  causing  the  feature.  At  any  point  in 
the  analysis  of  events,  a  list  of  candidate  faults  and  confidence  levels  for  the  test  can  be 
displayed  to  the  user.  These  faults  can  be  influenced  by  analysis  of  any  feature  in  the 
current  test.  The  system  will  be  capable  of  diagnosing  multiple,  dependent  faults. 

4. 5. 2. 3.1  Input 

A.  The  knowledge  base  (rule  base)  describing  the  relationships  between 
observed  anomalies,  historical  data,  maintenance  and  inspection  reports 
time/life  considerations  and  hardware  failures. 

B .  Diagnostic  facts  for  each  match  or  partial  match  of  an  anomalous  feature  in  a 
test  data  channel  or  other  facts  concerning  inspection  reports,  configuration 
and  history. 

C.  Confidence  levels  in  the  facts. 

4. 5. 2. 3. 2  Process 

A.  Open  Knowledge  base  files  and  feature  (fact)  files  maintained  bv 
NEXPERT  Object  shell. 

B.  Select  anomaly  or  continue  with  diagnosis  of  anomaly  if  previously 
initiated. 
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MCC  LN 


TEST  ANOMALY  DETAIL 

FEATURE.  UNDERSHOOT  ABOVE  2o  THRESHOLD 

EST.  A2-492 

’HASE  START  DIAGNOSIS;  UNKNOWN 


MCC  2020 


ADDITIONAL  DATA 
PRIOR  TEST 
MCC  HIST 


SIM.  ANOMALV 


FIGURE  4-14  Pre-Defined  Plot  Format  Is  Available  During  Diagnosis  to 
Show  Basis  of  Feature  Detection 


78 


C.  Perform  inference  step  (back/forward  chain).  If  in  "Auto"  mode,  continue 
until  no  more  facts  can  be  inferred.  If  in  "Step"  mode,  halt  before  firing 
next  rule  and  allow  user  options  (as  follows). 

D.  On  user  selection,  retrieve  pre-defined  report  for  rule.  Tnis  can  be  a  plot  of 
test  data,  retrieval  on  other  tables  in  integrated  database  or  other  report 
containing  data  related  to  the  rule  clauses  (for  example,  see  Figure  4-15). 

E.  On  user  selection,  allow  user  access  to  the  CAE  environment  with  default 
selections  set  to  this  test,  phase,  and  anomaly. 

F.  On  user  selection,  suspend  diagnosis  process  and  store  parameters  required 
to  restart  process  at  suspended  point.  Exit  to  main  menu. 

G.  On  user  selection,  obtain  background  information  using  hypertext  help 
system  with  errry  defined  by  specific  rule  being  examined  and  dynamic 
hypertext  indices  set  up  for  this  test,  phase,  anomaly,  etc.  to  define  context 
of  help.  This  system  can  contain  dynamic  graphics  provided  by  the  user 
interface  (DataViews  or  SL). 

H.  On  user  selection,  alter  state  of  one  or  more  facts  and/or  confidences 
concerning  features  or  intermediate  conclusions. 

I.  On  user  selection,  allow  a  completed  diagnosis  to  be  stored  in  anomalies 
database  (see  Figure  4-16)  which  contains  a  history  of  diagnostic  results 
including  follow-up  narratives,  related  inspection  reports,  etc.. 

J.  On  user  selection,  obtain  a  window  with  transaction  log  tracing  the 
inference  process  as  it  has  progressed  to  this  point. 

K  .  On  user  selection,  obtain  a  graphical  representation  of  the  inference  network 
showing  actual  status  of  inference  to  this  point. 

L.  Proceed  to  next  inference  step. 

4. 5. 2. 3. 3  Output 

A.  Diagnosis(es)  of  hardware  or  test  failure  or  indication  of  a  "false  alarm" 
based  upon  reasoning  controlled  by  the  rules  in  the  knowledge  base. 

B .  Explanation  of  reasoning  path  which  lead  to  the  conclusion(s). 

C.  Other  supporting  data  used  to  clear  the  fault  or  make  recommendations 
concerning  its  importance  and  disposition. 

4. 5. 2. 4  Advanced  Diagnostics  (External  Applications) 

4.5.2.4.1  Input 

A  Diagnostic  facts  for  each  match  or  partial  match  of  an  anomalous  feature  in  a 
test  data  channel  or  other  facts  concerning  inspection  reports,  configuration 
and  history. 
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FIGURE  4-15  Expert  Aided  Diagnostics  Provides  a  Rule 

Controlled  Analysis  of  Test  Data  and  Related 
Information 
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HISTORY  OF  SiniLAR  ANOMALIES 

PARAMETER:  MCC  LN  CAV  PR 

ANOMALY  UNDERSHOOT  ABOVE  2o  THRESHOLD 


RLE 

TEST 

LAI£ 

PHASE 

DIAGNOSIS 

SI 

A  1-242 

1/12/88 

START 

FACILITY  PURGE  REQUIRED 

S2 

A2-296 

2/20/89 

START 

FACILITY  PURGE  REQUIRED 

S3 

A  1-3 47 

4/17/89 

START 

MCC  LN  CAV  SENSOR  FAULT 

S4 

A2-310 

5/30/89 

START 

UNKNOWN 

S5 

A2-395 

10/10/89 

START 

FACILITY  PURGE  REQUIRED 

S6 

A2-400 

11/1/89 

START 

FACILITY  PURGE  REQUIRED 

FIGURE  4-16  Completed  Diagnoses  Are  Incorporated  Into  Integrated 
Database 
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B .  Confidence  levels  in  the  facts. 

C .  Other  files  dependent  upon  the  external  application. 

4. 5. 2. 4. 2  Process 


The  workstation  allows  integration  of  externally  generated  applications  (using  the 
NEXPERT  Object  shell)  to  perform  additional,  focused  diagnostics  using  information 
available  from  the  integrated  databases  and  interfacing  with  the  fact  (blackboard)  files.  For 
example,  a  deep  reasoning  inference  model  could  be  used  to  detect  and  isolate  problems  in 
the  HPOTP  using  the  internal  thermodynamic  relationships  of  the  hardware.  Applications 
of  this  type  could  use  the  expert  system/CAE  environment  established  by  the  workstanon  to 
obtain  data  and  additional,  related  information.  The  interface  between  applications  could 
then  be  implemented  in  a  seamless  manner  with  little  impact  on  the  user  interface. 


4. 5. 2. 4. 3  Output 


A.  Diagnosis(es)  of  hardware  or  test  failure  or  indication  of  a  "false  alarm" 
based  upon  reasoning  controlled  by  the  rules  in  the  knowledge  base; 


B.  Explanation  of  physical  reasoning  used  to  derive  failure  diagnosis  using 
"deep"  inference  methods;  and 

C.  Other  supporting  data  used  to  clear  the  fault  or  make  recommendations 
concerning  its  importance  and  disposition. 


4.6  SYSTEM  ADMINISTRATION 
4.6.1  Piuabase  Administration 

Database  administration  will  be  performed  using  file  maintenance  programs 
included  in  Ingres.  Functions  will  include  data  dictionary  modification,  data  table  edits, 
and  table  loading.  Additionally,  pre-defined  plot  formats  will  be  maintained  by  the 
database  administrator  so  that  standard  plot  sets  can  be  produced  by  each  workstation  for 
each  test.  Local  definition  of  pre-defined  plot  formats  will  be  the  responsibility  of 
individual  analysts. 


4.6.2  Database  Backup/Recoverv 

Data  backup  and  recovery  will  utilize  programs  incorporated  in  the  SUN  and  VAX 
processor  platform  workstations.  File  server  backups  will  protect  data  from  short  term 
loss.  Long  term  file  backups  will  be  based  upon  PE4  mass  storage.  Workstation  data 
backups  and  recovery  will  be  the  responsibility  of  local  analysts  using  existing  workstation 
utilities. 

4.6.3  Svstem  Installation/Reconfiguration 

Software  installation,  reinstallation  and  reconfiguration  will  be  controlled  by  this 
program.  In  addition  to  customizing  the  workstation  programs  to  the  analysis  functions  of 
the  specific  workstation,  the  program  will  install  Ethernet  vLAN  programs  necessary  for 
system  operation. 


4.6.4  System  Security 


System  security  will  be  provided  to  prevent  unauthorized  use  of  the  system  and  to 
restrict  write  priveledges  to  the  integrated  databases  and  the  diagnostic  rule  modules.  The 
system  will  require  a  user  password  to  enter  the  main  diagnostic  system  menu.  This 
password,  in  addition  to  restricting  user  access,  will  also  determine  the  user  priveledges. 
Specific  user  priveledge  will  be  required  to  edit  the  contents  of  the  integrated  database  and 
to  modify  the  diagnostic  rule  base.  The  password  system  will  be  maintained  by  the 
database  administrator. 

Simultaneous  access  to  data  by  multiple  users  will  be  controlled  by  file  and  record 
locking  utilities  provided  under  Ingres. 
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5.0 


IMPLEMENTATION  PLAN 


Diagnostic  workstation  implementation  will  be  incremental  to  maximize  user  input 
during  the  expert  system  software  design  and  assure  that  the  initial  benefits  of  the  system 
reach  the  user  as  quickly  as  possible. 

The  implementation  program  is  split  into  three  phases  (see  Figure  5-1).  Each  phase 
results  in  increased  system  capability,  and  will  permit  evaluation  and  comment  by  the 
users.  During  this  evaluation  period,  design  adjustments  can  be  made  and  software 
revisions  performed  that  will  protect  the  overall  program  schedule.  At  the  end  of  each 
evaluation  period,  the  software  for  that  increment  will  be  frozen  in  preparation  for  upgrade 
in  the  subsequent  phase.  At  the  completion  of  the  program,  the  workstation  software  will 
be  validated  and  ready  for  installation  at  multiple  MSFC  analysis  locations. 

In  the  first  phase,  the  work  effort  will  be  directed  to  establishing  the  integrated 
database  environment  on  the  networked  workstation.  The  applications  described  in  Section 
3.4.2. 1  and  3. 4. 2. 2  will  be  implemented  during  this  phase.  Commercial  graphics,  data 
analysis  and  statistics  packages  will  be  integrated  into  this  environment  and  the  basic 
"toolbox"  capabilities  provided.  An  evaluation  workstation  will  be  installed  at  MSFC  for 
evaluation  by  the  systems  group.  During  the  phase  1  period,  users  will  access  data  from 
SSME  tests  and  maintain  historical  and  configuration  files  within  the  system.  At  end  of  the 
evaluation,  the  integrated  CAE  environment  should  be  fully  established  and  data  access 
validated. 

In  the  second  phase,  special  application  programs,  described  in  Section  3. 4. 2. 3, 
will  he  integrated  into  the  CAE  environment.  The  applications  include  automated 
diagnostic  routines  for  SSME  test  phases,  two-sigma  exceedance  packages,  analytical 
redundancy  and  power  balance  model  integration.  These  funcuons  will  be  specified  in  the 
software  design,  implemented  and  tested  in  the  development  environment  and  then  installed 
in  the  evaluation  platform  for  user  operation.  Again,  user  comments  will  be  incorporated 
into  the  functionality.  At  the  end  of  the  evaluation  period  this  portion  of  the  workstation 
software  will  be  validated. 

The  last  phase  of  the  implementation  will  involve  integration  of  expert-aided 
diagnostics  into  the  enhanced  CaE  environment  using  applications  described  in  Section 
3.4. 2.4.  The  design  of  the  knowledge  base  and  the  procedural  elements  of  the  system  will 
benefit  from  user  experience  with  the  incremental  workstation  funcuons  and  the  acquisiuon 
of  expert  knowledge  will  be  significantly  more  productive  under  these  circumstances.  The 
expert  system  software  will  be  specified,  including  the  knowledge  bases  and  integrated  into 
the  evaluation  system.  Additional  software  being  developed  for  SSME  applications  under 
other  programs  such  as  the  HPOTP  diagnostic  and  health  assessment  system  could  be 
integrated  into  the  workstation  environment  during  this  phase.  Finally,  there  will  be  an 
evaluation  period  during  w'hich  the  users  will  be  supported  to  adjust  and  enhance  the 
operation  of  the  system  and  tailor  it  precisely  to  their  requirements. 

At  the  completion  of  the  effort,  the  workstation  applications  will  have  been  fully 
validated  and  the  software  will  be  ready  for  installation  at  multiple  locations  at  the  data 
analysis  site. 
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